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INTRODUCTION 





MIDI, the Musical Instrument Digital Interface, was established as a hardware and software 
specification which would make it possible to exchange information (musical notes, program changes, 
expression control, etc.) between different musical instruments or other devices such as sequencers, 
computers, lighting controllers, mixers, etc. This ability to transmit and receive data was originally 
conceived for live performances, although subsequent developments have had enormous impact in 
recording studios, audio and video production, and composition environments. 


This document has been prepared as a joint effort between the MIDI Manufacturers Association (MMA) 
and the Japan MIDI Standards Committee (JMSC) to explain the MIDI 1.0 specification. This document 
is subject to change by agreement between the JMSC and MMA. Additional MIDI protocol may be 
included in supplements to this publication. 


HARDWARE 





The hardware MIDI interface operates at 31.25 (+/- 1%) Kbaud, asynchronous, with a start bit, 8 data 
bits (DO to D7), and a stop bit. This makes a total of 10 bits for a period of 320 microseconds per serial 
byte. The start bit is a logical 0 (current on) and the stop bit is a logical 1 (current off). Bytes are sent 
LSB first. 


Circuit: (See Schematic - Page 2).5 mA current loop type. Logical 0 is current ON. One output shall 
drive one and only one input. To avoid ground loops, and subsequent data errors, the transmitter 
circuitry and receiver circuitry are internally separated by an opto-isolator (a light emitting diode and a 
photo sensor which share a single, sealed package). Sharp PC-900 and HP 6N138 opto-isolators have 
been found acceptable. Other high-speed opto-isolators may be satisfactory. The receiver must require 
less than 5 mA to turn on. Rise and fall times should be less than 2 microseconds. 


Connectors: DIN 5 pin (180 degree) female panel mount receptacle. An example is the SWITCHCRAFT 
57 GB5F. The connectors shall be labeled "MIDI IN" and "MIDI OUT". Note that pins 1 and 3 are not 
used, and should be left unconnected in the receiver and transmitter. Pin 2 of the MIDI In connector 
should also be left unconnected. 


The grounding shield connector on the MIDI jacks should not be connected to any circuit or chassis 
ground. 


When MIDI Thru information is obtained from a MIDI In signal, transmission may occasionally be 
performed incorrectly due to signal degradation (caused by the response time of the opto-isolator) 
between the rising and falling edges of the square wave. These timing errors will tend to add up in the 
"wrong direction" as more devices are chained between MIDI Thru and MIDI In jacks. The result is that, 
regardless of circuit quality, there is a limit to the number of devices which can be chained (series- 
connected) in this fashion. 
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MIDI Standard Hardware 
NOTES: 


1. Opto-isolator currently shown is Sharp PC-900 
(HP 6N138 or other opto-isolator can be used with appropriate changes.) 


2. Gates "A" are IC or transistor. 

3. Resistors are 5% 

Cables shall have a maximum length of fifty feet (15 meters), and shall be terminated on each end by a 

corresponding 5-pin DIN male plug, such as the SWITCHCRAFT 05GM5M. The cable shall be shielded 

twisted pair, with the shield connected to pin 2 at both ends. 

A MIDI Thru output may be provided if needed, which provides a direct copy of data coming in MIDI In. 


For long chain lengths (more than three instruments), higher-speed opto-isolators should help to avoid 
additive rise/fall time errors which affect pulse width duty cycle. 


2 Overview 


DATA FORMAT 


MIDI communication is achieved through multi-byte "messages" consisting of one Status byte followed 
by one or two Data bytes. Real-Time and Exclusive messages are exception. 





A MIDI-equipped instrument typically contains a receiver and a transmitter. Some instruments may 
contain only a receiver or only a transmitter. A receiver accepts messages in MIDI format and executes 
MIDI commands. It consists of an opto-isolator, Universal Asynchronous Receiver/Transmitter (UART), 
and any other hardware needed to perform the intended functions. A transmitter originates messages in 
MIDI format, and transmits them by way of a UART and line driver. 


MIDI makes it possible for a user of MIDI-compatible equipment to expand the number of instruments 
in a music system and to change system configurations to meet changing requirements. 


MIDI messages are sent over any of 16 channels which are used for a variety of performance 
information. There are five major types of MIDI messages: Channel Voice, Channel Mode, System 


Common, System Real-Time and System Exclusive. 


A MIDI event is transmitted as a "message" and consists of one or more bytes. The diagrams below show 
the structure and classification of MIDI data. 


TYPES OF MIDI BYTES: 


Status Byte Data Byte 
(80H - FFH (OOH - 7FH) 





TYPES OF MIDI MESSAGES: 


Message Type 


—.- te 


Channel System 
Message Message 


—_—_, = _t————_ 


; m ystem ystem 
Channel Voice] Channel Mode ysten 
Message Message Exclusive Common Real Time 
Message Message Message 
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STRUCTURE OF A SINGLE MESSAGE: 


| Status _|~|_Data Byte 
| Status [— Data Byte | | Data Byte 


STRUCTURE OF SYSTEM EXCLUSIVE MESSAGES: 


| Status [~| Data Bytes [~|__EOX 


MESSAGE TYPES 





Messages are divided into two main categories: Channeland System. 


CHANNEL MESSAGES 


A Channel message uses four bits in the Status byte to address the message to one of sixteen MIDI 
channels and four bits to define the message (see Table II). Channel messages are thereby intended for 
the receivers in a system whose channel number matches the channel number encoded into the Status 
byte. 


An instrument can receive MIDI messages on more than one channel. The channel in which it receives 
its main instructions, such as which program number to be on and what mode to be in, is referred to as 
its "Basic Channel". An instrument may be set up to receive performance data on multiple channels 
(including the Basic Channel). These are referred to as "Voice Channels". These multiple-channel 
situations will be discussed in more detail later. 

There are two types of Channel messages: Voice and Mode. 


VOICE: To control an instrument's voices, Voice messages are sent over the Voice Channels. 


MODE: To define the instrument's response to Voice messages, Mode messages are sent over 
an instrument's Basic Channel. 


SYSTEM MESSAGES 


System messages are not encoded with channel numbers. There are three types of System messages: 
Common, Real-Time, and Exclusive. 


4 Overview 


COMMON: Common messages are intended for all receivers in a system regardless of 
channel. 


REAL-TIME: Real-Time messages are used for synchronization and are intended for all clock- 
based units in a system. They contain Status bytes only — no Data bytes. Real- 
Time messages may be sent at any time — even between bytes of a message 
which has a different status. In such cases the Real-Time message is either acted 
upon or ignored, after which the receiving process resumes under the previous 
status. 


EXCLUSIVE: Exclusive messages can contain any number of Data bytes, and can be 
terminated either by an End of Exclusive (EOX) or any other Status byte (except 
Real Time messages). An EOX should always be sent at the end of a System 
Exclusive message. These messages include a Manufacturer's Identification (ID) 
code. If a receiver does not recognize the ID code, it should ignore the following 
data. 


So that other users and third party developers can fully access their instruments, 
manufacturers must publish the format of the System Exclusive data following 


their ID code. Only the manufacturer can define or update the format following 
their ID. 


DATA TYPES 


There are two types of bytes sent over MIDI: Status Bytes and Data bytes. 





STATUS BYTES 


Status bytes are eight-bit binary numbers in which the Most Significant Bit (MSB) is set (binary 1). 
Status bytes serve to identify the message type, that is, the purpose of the Data bytes which follow it. 
Except for Real-Time messages, new Status bytes will always command a receiver to adopt a new status, 
even if the last message was not completed. 


RUNNING STATUS 


For Voice and Mode messages only. When a Status byte is received and processed, the receiver will 
remain in that status until a different Status byte is received. Therefore, if the same Status byte would 
be repeated, it can optionally be omitted so that only the Data bytes need to be sent. Thus, with Running 
Status, a complete message can consist of only Data bytes. 


Running Status is especially helpful when sending long strings of Note On/Off messages, where "Note 
On with Velocity of 0" is used for Note Off. 


Running Status will be stopped when any other Status byte intervenes. Real-Time messages should not 
affect Running Status. 


See also: Additional Explanations and Application Notes 
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UNIMPLEMENTED STATUS 


Any status bytes, and subsequent data bytes, received for functions not implemented in a receiver 
should be ignored. 


UNDEFINED STATUS 


All MIDI devices should be careful to never send any undefined status bytes. If a device receives any 
such code, it should be ignored without causing any problems to the system. Care should also be taken 
during power-up and power-down that no messages be sent out the MIDI Out port. Such noise, if it 
appears on a MIDI line, could cause a data or framing error if the number of bits in the byte are 
incorrect. 


DATA BYTES 


Following a Status byte (except for Real-Time messages) there are either one or two Data bytes which 
carry the content of the message. Data bytes are eight-bit binary numbers in which the Most Significant 
Bit (MSB) is always set to binary 0. The number and range of Data bytes which must follow each Status 
byte are specified in the tables in section 2. For each Status byte the correct number of Data bytes must 
always be sent. Inside a receiver, action on the message should wait until all Data bytes required under 
the current status are received. Receivers should ignore Data bytes which have not been properly 
preceded by a valid Status byte (with the exception of "Running Status," explained above). 


CHANNEL MODES 


Synthesizers and other instruments contain sound generation elements called voices. Voice assignment 
is the algorithmic process of routing Note On/Off data from incoming MIDI messages to the voices so 
that notes are correctly sounded. 





Note: When we refer to an "instrument" please note that one physical instrument may act as several 
virtual instruments (i.e. a synthesizer set to a 'split' mode operates like two individual instruments). 
Here, "instrument" refers to a virtual instrument and not necessarily one physical instrument. 


Four Mode messages are available for defining the relationship between the sixteen MIDI channels and 
the instrument's voice assignment. The four modes are determined by the properties Omni (On/Off), 
Poly, and Mono. Poly and Mono are mutually exclusive, 1.e., Poly disables Mono, and vice versa. Omni, 
when on, enables the receiver to receive Voice messages on all voice Channels. When Omni is off, the 
receiver will accept Voice messages from only selected Voice Channel(s). Mono, when on, restricts the 
assignment of Voices to just one voice per Voice Channel (Monophonic.) When Mono is off (Poly On), a 
number of voices may be allocated by the Receiver's normal voice assignment (Polyphonic) algorithm. 


6 Overview 


For a receiver assigned to Basic Channel "N," (1-16) the four possible modes arising from the two Mode 
messages are: 


Mode Omni 

1 On Poly Voice messages are received from all Voice channels and 
assigned to voices polyphonically. 

2 On Mono Voice messages are received from all Voice Channels, and 
control only one voice, monophonically. 

3 Off Poly Voice messages are received in Voice channel N only, and are 

assigned to voices polyphonically. 
4 Off Mono Voice messages are received in Voice channels N through N+M-1, 


and assigned monophonically to voices 1 through M, respectively. 
The number of voices "M" is specified by the third byte of the Mono 
Mode Message. 


Four modes are applied to transmitters (also assigned to Basic Channel N). Transmitters with no 
channel selection capability should transmit on Basic Channel 1 (N=1). 


Mode Omni 
1 On Poly All voice messages are transmitted in Channel N. 
2 On Mono Voice messages for one voice are sent in Channel N. 
3 Off Poly Voice messages for all voices are sent in Channel N. 
4 Off Mono Voice messages for voices 1 through M are transmitted in Voice 
Channels N through N+M-1, respectively. (Single voice per 
channel). 


A MIDI receiver or transmitter operates under only one Channel Mode at a time. If a mode is not 
implemented on the receiver, it should ignore the message (and any subsequent data bytes), or switch to 
an alternate mode, usually Mode 1 (Omni On/Poly). 


Mode messages will be recognized by a receiver only when received in the instrument's Basic Channel — 
regardless of which mode the receiver is currently assigned to. Voice messages may be received in the 
Basic Channel and in other Voice Channels, according to the above specifications. 


Since a single instrument may function as multiple "virtual" instruments, it can thus have more than 
one basic channel. Such an instrument behaves as though it is more than one receiver, and each receiver 
can be set to a different Basic Channel. Each of these receivers may also be set to a different mode, 
either by front panel controls or by Mode messages received over MIDI on each basic channel. Although 
not a true MIDI mode, instruments operating in this fashion are described as functioning in "Multi 
Mode." 
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An instrument's transmitter and receiver may be set to different modes. For example, an instrument 
may receive in Mono mode and transmit in Poly mode. It is also possible to transmit and receive on 
different channels. For example, an instrument may receive on Channel 1 and transmit on Channel 3. 


POWER-UP DEFAULT CONDITIONS 


It is recommended that at power-up, the basic channel should be set to 1, and the mode set to Omni 
On/Poly (Mode 1). This, and any other default conditions for the particular instrument, should be 
maintained indefinitely (even when powered down) until instrument panel controls are operated or 
MIDI data is received. However, the decision to implement the above, is left totally up to the designer. 
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CHANNEL VOICE MESSAGES 





Note-Off 8nH 
Note-On 9nH 
Poly Key Pressure AnH 
Control Change BnH (0-119) 
Program Change CnH 
Channel Pressure DnH 
Pitch Bend EnH 





Channel Voice Messages are the bulk of information transmitted between MIDI instruments. They 
include all Note-On, Note-Off, program change, pitch-wheel change, after-touch pressure and controller 
changes. These terms are defined below. 


A single Note-On message consists of 3 bytes, requiring 960 microseconds for transmission. When many 
notes are played at the same time, the multiple Note-On messages may take several milliseconds to 
transmit. This can make it difficult for MIDI to respond to a large number of simultaneous events 
without some slight audible delay. This problem can be relieved to some degree by using the Running 
Status mode described on page 5 and in the appendix (A1-3). 


TYPES OF VOICE MESSAGES 


NOTE-ON: Message is sent by pressing a key or from other triggering devices. 
NOTE-OFF: Message is sent by releasing a key. 
CONTROL CHANGE: Message is sent when a controller other than a key (e.g. a pedal, 


wheel, lever, switch, etc.) is moved in order to modify the sound of a 
note (e.g. introducing modulation, sustain, etc.). Control changes 
are not used for sending parameters of tones (voices), such as 
attack time, filter cut off frequency, etc. 


PROGRAM CHANGE: When a "program" (i.e. sound, voice, tone, preset or patch) is 
changed, the number corresponding to the newly selected program 
is transmitted. 


AFTER TOUCH: This message typically is sent by key after-pressure and is used to 
modify the note being played. After touch messages can be sent as 
Polyphonic Key Pressure or Channel Pressure. 


PITCH BEND CHANGE: _ This message is used for altering pitch. The maximum resolution 
possible is 14 bits, or two data bytes. 


Voice messages are not exclusively for use by keyboard instruments, and may be transmitted for a 


variety of musical purposes. For example, Note-On messages generated with a conventional keyboard 
synthesizer may be used to trigger a percussion synthesizer or lighting controller. 
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NOTE NUMBER 


Each note is assigned a numeric value, which is transmitted with any Note-On/Off message. Middle C 
has a reference value of 60. This is the middle C of an 88 note piano-style keyboard though it need not be 
physically located in the center of a keyboard. 


0 12 24 36 48 60 72 84 96 108 120 127 


ac Cc Cc Cc Cc Cc Cc Cc 


| piano range | 


VELOCITY 


Interpretation of the Velocity byte is left up to the receiving instrument. Generally, the larger the 
numeric value of the message, the stronger the velocity-controlled effect. If velocity is applied to volume 
(output level) for instance, then higher Velocity values will generate louder notes. A value of 64 (40H) 
would correspond to a mezzo-forte note and should also be used by device without velocity sensitivity. 
Preferably, application of velocity to volume should be an exponential function. This is the suggested 
default action; note that an instrument may have multiple tables for mapping MIDI velocity to internal 
velocity response. 


0 1 64 127 


off ppp p pp mp mf f ff fff 


vvvvvvv = 64: if not velocity sensitive 
vvvvwvv = 0: Note-Off (with velocity of 64) 


NOTE-OFF 


MIDI provides two roughly equivalent means of turning off a note (voice). A note may be turned off 
either by sending a Note-Off message for the same note number and channel, or by sending a Note-On 
message for that note and channel with a velocity value of zero. The advantage to using "Note-On at 
zero velocity" is that it can avoid sending additional status bytes when Running Status is employed. 


Due to this efficiency, sending Note-On messages with velocity values of zero is the most commonly used 
method. However, some keyboard instruments implement release velocity where a Note-Off code (8nH) 
accompanied by a "velocity off" byte is used. A receiver must be capable of recognizing either method of 
turning off a note, and should treat them identically. 


The three methods of using Note-On (9nH) or Note-Off (8nH) are as follows: 
1. For a keyboard which does not implement Velocity, the note will be turned on using 9n, 


kkkkkkk, 64 (40H) and may be turned off using 9n, Okkkkkkk, 00000000 or 8n, Okkkkkkk, 
Oxxxxxxx (a value of 64 [40H] is used for x). 
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2. For a keyboard which incorporates Key On Velocity, but not Release Velocity the note is 
turned on using 9n Okkkkkkk, Ovvvvvvwv and may be turned off using 9n, Okkkkkkk, 00000000 or 
8n, Okkkkkkk, Oxxxxxxx (a value of 64 (40H) is recommended for x). 


3. Where the keyboard implements both Key On Velocity and Release Velocity, a note is turned 
on using 9n Okkkkkkk, Ovvvvvvv, and turned off using 8n, Okkkkkkk, Ovvvvvvv. 


CONTROL CHANGE 


The Control Change message is generally used for modifying tones with a controller other than a 
keyboard key. It is not for setting synthesizer parameters such as VCF cut-off, envelope decay, etc. 
There are some exceptions to the use of the Control Change message, such as the special Bank Select 
message and the RPN/NRPN messages (listed below). 


CONTROLLER NUMBERS 


All controller number assignments are designated by agreement between the MMA and JMSC. The 
numbers listed in Table III are specified for standard musical instrument applications. However, many 
non-musical devices which implement MIDI, such as lighting controllers, may use designated controller 
numbers at their discretion. Due to the limited number of controller numbers it would be impossible to 
assign a number to every possible effect (musical and non-musical) used now and in the future. For this 
reason, controllers are generally assigned only for purposes associated with musical instruments. 


It is up to the manufacturer to inform their users of the fact that a device is using non-standard 
controller assignments. Though controllers may be used for non-musical applications, they must still be 
used in the format detailed in Table II. Manufacturers can request through the MMA or JMSC that 
logical controllers be assigned to physical ones as needed. A controller allocation table should be 
provided in the user's operation manual of all products. 


A manufacturer wishing to control a number of device-specific parameters over MIDI should used non- 
registered parameter numbers and the Data Entry controllers (Data Entry Slider, Increment, and 
Decrement messages) as opposed to a large number of controllers. This alleviates possible conflict with 
devices responding to the same control numbers unpredictably. 


There are currently 120 controller numbers, from 0 through 119 (controller 120 was recently adopted as 
a Channel Mode Message and is no-longer considered a Control Change). As shown below, controller 
numbers 382 to 63 are used to define an LSB byte for corresponding controllers 0 through 31. Controller 
classifications are as follows: 


0 through 31 = MSB of most continuous Controller Data 
32 through 63 LSB for controllers 0 through 31 
64 through Additional single-byte controllers 
96 through 101 Increment/Decrement and Parameter numbers 
102 through 119 = Undefined single-byte controllers 


co 
on 
II 


A numeric value (controller number) is assigned to the controllers of the transmitting instrument. A 
receiver may use the message associated with a controller number to perform any operation or achieve 
any desired effect. Further, a single controller number may be used to change a number of parameters. 
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controller numbers are classified by various categories. Each controller number corresponds to one byte 
of data. 


Controller numbers 0 through 31 are for controllers that obtain information from pedals, levers, wheels, 
etc. Controller numbers 32 through 63 are reserved for optional use as the LSB (Least Significant Byte) 
when higher resolution is required and correspond to 0 through 31 respectively. For example, controller 
number 7 (Volume) can represent 128 steps or increments of some controller's position. If controller 
number 39, the corresponding LSB number to controller number 7, is also used, 14-bit resolution is 
obtained. This provides for resolution of 16,384 steps instead of 128. 


If 128 steps of resolution is sufficient the second byte (LSB) of the data value can be omitted. If both the 
MSB and LSB are sent initially, a subsequent fine adjustment only requires the sending of the LSB. The 
MSB does not have to be retransmitted. If a subsequent major adjustment is necessary the MSB must be 
transmitted again. When an MSB is received, the receiver should set its concept of the LSB to zero. 


All controller numbers 64 and above have single-byte values only, with no corresponding LSB. Of these, 
64 through 69 have been defined for switched functions (hold pedal, etc.) while 91 through 95 are for 
controlling the depth of certain external audio effects. 


Control numbers 64 through 69 are assigned to functions normally associated with switches (i.e. sustain 
or soft pedals). However these controllers can be used to send any continuous value. The reverse can 
also be true for a continuous controller such as Modulation Wheel. While this controller is most often 
used as a variable control, an on/off modulation switch can also be used. This would be accomplished by 
sending the Modulation Controller number (01) and a data byte of either 0 (off) or 127 (on). 


If a receiver is expecting switch information it should recognize 0-63 (OOH-3FH) as "OFF" and 64-127 
(40H-7FH) as "ON". This is because a receiver has no way of knowing whether the message information 
is from a switch or a continuous controller. It is very important to always use an existing control 
number. The control numbers already adopted for use are listed in Table III. We will discuss some of 
them, but not all, below. 


GLOBAL CONTROLLERS 


If a receiving instrument is in Mode 4 (Omni Off/Mono) and is thus able to respond to more than one 
MIDI channel, it is possible to use a Global Controller to affect all voices regardless of MIDI channel. 
This is accomplished by sending any controller intended to affect all voices over the MIDI channel one 
below the basic channel of the receiver. For example, if a receiving synthesizer in Mode 4 is responding 
to channels 6 through 12, its basic channel is 6. Any controllers received on channel 5 would be Global 
Controllers and would affect all voices. If the Basic Channel is 1, then the Global Channel wraps to 
become 16, though not all receivers may provide this function. 


GENERAL PURPOSE CONTROLLERS 


Controller numbers 16-19 and 80-88 are defined as General Purpose Controllers. They may be used by a 
manufacturer for any added functions able to send or receive some sort of control information needed for 
a specific product. They do not have any intrinsic functions assigned to them. General Purpose 
Controllers 16-19 are two byte controllers (with controller numbers 48-51 for an optional LSB). General 
Purpose Controllers 80-83 are single byte controllers. As an example, an instrument with a special, user 
definable joystick or lever assignable to any internal parameter could send and receive General Purpose 
Controller numbers for sequencing. 
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CONTROLLER EFFECT 


All transmitters should send a value of 00 to represent minimum and 127 (7FH) to represent maximum. 
For continuous controllers without a center detented position, it is recommended that the minimum 
effect position correspond to 00, and the maximum effect position correspond to 127 (7FH). 


Virtually all controllers are defined as 0 being no effect and 127 being maximum effect. There are three 
defined controllers that are notably different: Balance, Pan and Expression. 


BALANCE: A Balance Controller has been adopted as continuous controller number 8 
(08H) with value 00 = full volume for the left or lower half, 64 (40H) = equal 
balance, and 127 (7FH) = full volume for the right or upper half. This 
controller determines the volume balance between two different sound 
sources. 


PAN: A Pan Controller has been adopted as continuous controller number 10 (OAH) 
with value 00 = hard left, 64 (40H) = center, and 127 (7FH) = hard right. This 
controller determines where a single sound source will be located in a stereo 
field. 


EXPRESSION: An Expression Controller has been adopted as continuous controller number 
11 (OBH). Expression is a form of volume accent above the programmed or 
main volume. 


BANK SELECT 


Bank Select is a special controller. The Bank Select message is an extension of the Program Change 
message and is used to switch between multiple banks. For example, a bank select message could be 
used to select more than 128 programs, or switch between internal memory and external RAM card. 


Control Change numbers 00H and 20H are defined as the Bank Select message. 00H is the MSB and 
20H is the LSB for a total of 14 bits. This allows 16,384 banks to be specified. 


The transmitter must transmit the MSB and LSB as a pair, and the Program Change must be sent 
immediately after the Bank Select pair. If their is any delay between these messages and they are 
passed through a merging device (which may insert another message) the message may be interpreted 
incorrectly. 


The messages Bank Select MSB, LSB and Program number will select a specific program. After 
switching to another bank, any Program Change messages transmitted singularly will select other 
program in that bank. 


After the receiver as received the entire Bank Select messages it will normally change to a new program. 
The program must change upon the receipt of the Program Change message. However, the program 
need not be changed for a note which is already sounding. When the Bank Select message is received, 
the receiving device must remember that bank number in readiness for the following Program Change. 
Bank Select alone must not change the program. This is to assure that multiple devices change 
concurrently. 
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The 14 bit Bank Select value corresponds to bank numbers as follows: 


MSB LSB Bank Number 
OOH OOH Bank 1 

OOH 7FH Bank 128 

01H OOH Bank 129 

7FH 7FH Bank 16,384 


As with program numbers, banks begin counting from 1. Thus the actual bank number will be (MIDI 
value + 1). 


LEGATO FOOTSWITCH 


Bn 44 vv Legato Footswitch 
vv = 00-3F Normal 
vv = 40-7F Legato 


Legato Footswitch is a recent addition to the specification. This controller is used to turn monophonic 
legato response in a receiving instrument on and off. When turned on the instrument goes into a 
monophonic mode; if a new Note-On is received before the Note-Off for the currently sounding note, 
pitch is changed without re-attacking the envelopes or (if possible) playing the attack portion of the 
sound. When turned off the voice assignment mode (polyphonic or monophonic) returns to the state it 
was in prior to receiving the Legato On command. 


Note: This message is not a replacement for proper Mode 4 legato operation. Nor is it a replacement for 
sending Note-Offs for every Note-On sent. It is specifically intended as a useful performance controller. 


EFFECTS CONTROLLER REDEFINITION 


Controller numbers 91 — 95 are defined as Effects Depth 1 through Effects Depth 5 and can be used for 
controlling various effects. Their former titles of External Effects Depth, Tremolo Depth, Chorus Depth, 
Celeste (Detune) Depth, and Phaser Depth are now the recommended defaults. 


SOUND CONTROLLERS 


Controllers 46H through 4FH are defined as “Sound Controllers.” Manufacturers and users may map 
any functions they desire to these ten controllers. However, to further aid standardization and easy set- 
up for users, the MMA and JMSC may determine “default” assignments for these controllers. A 
manufacturer may independently assign other functions to these controllers, but it should be understood 
that the MMA and JMSC may later assign different defaults to them. 


Five Sound Controller defaults have currently been defined by the MMA and JMSC: 





Number Name Instruments 

46H (70) Sound Controller #1 Sound Variation 

47H (71) Sound Controller #2. Timber/Harmonic Intensity 
48H (72) Sound Controller #3 Release Time 

49H (73) Sound Controller #4 Attack Time 

4AH (74) Sound Controller #5 Brightness 
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SOUND VARIATION CONTROLLER: 
Bn 46 vv Sound Variation 


This controller is used to select alternate versions of a sound during performance. Note that it is 
different from a program change in several ways: 


1. The variation (alternate sound) is an intrinsic part of the program which is being played, and 
is programmed in the patch. 


2. The variation is usually related to the primary sound — for example, a sax and an overblown 
sax, bowed and pizzicato strings, a strummed and muted guitar, etc. 


3. The variation to be used is decided at the time of the Note-On. For example, if the value of 
SVC is set to 00, notes are sounded, and then SVC is changed to 24H, the notes currently 
sounding will not change. Any new notes will take the variation determined by the new SVC 
value. If the old notes are released, they will finish in their original manner. 


SVC actually acts as a multi-level switch. An instrument’s levels of variations should be mapped 
over the entire 00-7FH range of the controller. For example, if an instrument had only a single SVC 
switch, it would transmit a value of 00) for the primary sound and 7FH for the secondary sound. If 
an instrument had four variations, it would transmit these as 00, 20H, 40H, and 7FH. The first 
instrument would receive any value in the range of 40H-7FH to select its secondary sound. 


TIMBRE CONTROLLERS: 


Bn 47 vv Timbre/Harmonic Intensity 
Bn 4A vv Brightness 


The Harmonic Content controller (commonly known as “timbre”) is intended as a modifier of the 
harmonic content of a sound, e.g. FM feedback, FM modulation amount, waveform loop points, etc. 
The receiving instrument determines the application of this controller according to its voice 
architecture. 


Harmonic Content should be treated as an absolute rather than relative value, and should be 
handled as a modulation input by the receiver. 


The Brightness controller is aimed specifically at altering the brightness of the sound. In most sound 
modules, it would correspond to a low pass filter’s cutoff frequency, although it might also control 
EQ or a harmonic enhancer/exciter. 


Brightness should be treated as a relative controller, with a data value of 40H meaning no change, 
values less than 40H meaning progressively less bright, and values greater than 40H meaning 
progressively more bright. 


Both of these controllers are intended as a performance controllers — not as a sound parameter 
editing controllers (in other words, these messages do not change the memorized data of a preset). 
They have no fixed association with any physical controller. 


The receiving instrument should be able to respond to these controllers while sustaining notes 


without audible glitches or re-triggering of the sound. The effective range of these controllers may be 
programmed per preset, if desired. 
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ENVELOPE TIME CONTROLLERS: 


Bn 48 vv Release Time 

Bn 49 vv Attack Time 
vv = 00 - 3F =shorter times (00 = shortest adjustment) 
vv = 40 = no change in times 
vv = 41 - 7F = Jonger times (7F = longest adjustment) 


These controllers are intended to adjust the attack and release times of a sound relative to its pre- 
programmed values. The manufacturer and user should decide which envelopes in a voice are 
affected; the default should be all envelopes. These controllers should affect all envelopes affected 
about to enter their release or attack phases (respectively); the manufacturer may allow an option to 
affect envelope phases already started. 


These envelope time controllers do not replace the effect attack or release velocity may have on the 
envelope times of the sound; they should interact with them in a predictable manner. They have no 
fixed association with a physical controller. The effective range of these controllers may be 
programmed per preset, if desired. 


These are intended as a performance controllers — not as a sound parameter editing controllers (in 
other words, these messages do not change the memorized data of a preset). The receiving 
instrument should be able to respond to these controllers while sustaining notes and without audible 
glitches or re-triggering of the sound. 


PORTAMENTO CONTROLLER 


Bn 54 kk 
n = channel 
kk = source note number for pitch reference 


Portamento Control (PTC) is a recent addition, and defines a continuous controller that communicates 
which note number the subsequent note is gliding from. It is intended for special effects in playing back 
pre-sequenced material, so that legato with portamento may be realized while in Poly mode. 


When a Note-On is received after a Portamento Control message, the voice’s pitch will glide from the key 
specified in the Portamento Control message to the new Note-On’s pitch at the rate set by the 
portamento time controller (ignoring portamento on/off). 


A single Portamento Control message only affects the next Note-On received on the matching channel 
(i.e. it is reset after the Note-On). Receiving a Portamento Control message does not affect the pitch of 
any currently sustaining or releasing notes in Poly modes; if in Mono mode or if Legato Footswitch is 
currently on, a new overlapped note event would result in an immediate pitch jump to the key specified 
by the portamento Control message, and then a glide at the current portamento rate to the key specified 
by the new Note-On. 


In all modes, the note is turned off by a note that matches the Note-On key number: not the key number 
stated in the Portamento Control message. Pitch bend offsets the pitch used by both the Portamento 
Control starting note and the target Note-On. 


If there is a currently sounding voice whose note number is coincident with the source note number, the 


voice’s pitch will glide to the new Note-On’s pitch according to the portamento time without re-attacking. 
Then, no new voice should be assigned. 
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The single Portamento Control message only affects the next Note-On received on the matching channel 
(in other words, it is reset after the Note-On). Receiving a Portamento Control message does not affect 
the pitch of other currently sounding voices except a voice whose note number is coincident with the 
source key number of the Portamento Control message in Poly mode. 








Example 1- 

MIDI Message Description Result 

90 3c 40 Note-On #60 #60 on (middle C) 

BO 54 3C PTC from #60 no change in current note 
90 40 40 Note-On #64 re-tune from #60 to #64 
80 3C 40 Note-Off #60 no change 

80 40 40 Note-Off #64 #64 off 

Example 2: 

MIDI Message Description Result 

BO 54 3C PTC from #60 no change 

90 40 40 Note-On #64 #64 with glide from #60 
80 40 40 Note-Off #64 #64 Off 


REGISTERED AND NON-REGISTERED PARAMETER NUMBERS 


Registered and Non-Registered Parameter Numbers are used to represent sound or performance 
parameters. As noted below, Registered Parameters Numbers are agreed upon by the MMA and JMSC. 
Non-Registered Parameter Numbers may be assigned as needed by individual manufacturers. The basic 
procedure for altering a parameter value is to first send the Registered or Non-Registered Parameter 
Number corresponding to the parameter to be modified, followed by the Data Entry, Data Increment, or 
Data Decrement value to be applied to the parameter. 


There are several rules and suggestions as to the use of these parameter numbers and controllers: 


1. A manufacturer may assign any desired parameter to any Non-Registered Parameter Number. 
This list should be published in the owner's manual. 


2. Reception of Non-Registered Parameter Numbers should be disabled on power-up to avoid 
confusion between different machines. Transmission of these numbers should be safe at any time 
if this is done. 


3. After the reception of Non-Registered (or Registered) Parameter Numbers has been enabled, the 
receiver should wait until it receives both the LSB and MSB for a parameter number to ensure 
that it is operating on the correct parameter. 


4. The receiver should be able to respond accordingly if the transmitter sends only an LSB or MSB to 
change the parameter number. However, since the transmitter can't know when reception was 
enabled on the receiver which will be waiting for both the LSB and MSB (at least initially), it is 
recommended that the LSB and MSB be sent each time a new parameter number is selected. 


5. The Registered Parameter Numbers are agreed upon by the MMA and JMSC. Since this is a 
standardized list, reception of these Registered Parameter Numbers may be enabled on power-up. 


6. Once a new Parameter Number is chosen, that parameter retains its old value until a new Data 
Entry, Data Increment, or Data Decrement is received. 
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PITCH BEND SENSITIVITY: 


Pitch Bend Sensitivity is defined as Registered Parameter Number 00 00. The MSB of Data Entry 
represents the sensitivity in semitones and the LSB of Data Entry represents the sensitivity in 
cents. For example, a value of MSB=01, LSB=00 means +/- one semitone (a total range of two 
semitones). 


MASTER TUNING: 


Registered Parameter numbers 01 and 02 are used for Master Tuning control. They are 
implemented as follows: 


ERPN O01 - FINE TUNING: 





Resolution: 100/8192 cents 

Range: 100/8192* (-8192) to 100/8192* (+8191) 
Control Value _ Displacement in cents from A440 
MSB LSB 

00 00 100/8192* (-8192) 

40H 00 100/8192* (0) 

7FH 7FH 100/8192* (+8191) 


RPN 02 - COARSE TUNING: 





Resolution: 100 cents 
Range: 100* (-64) to 100* (+63) 
Control Value _ Displacement in cents from A440 
MSB LSB 
00 XX 100* (-64) 
40H XX 100* (0) 
7FH xx 100* (+63) 
PROGRAM CHANGE 


This message is used to transmit the program or "patch" number when changing sounds on a MIDI 
instrument. The message does not include any information about the sound parameters of the selected 
tone. As the various parameters that constitute a program are very different from one MIDI instrument 
to another it is much more efficient to address a sound simply by its internal number. 


Program Change messages are most often sent when physically selecting a new sound on an instrument. 
However, if the transmitting instrument does not produce its own sound, a button or any other physical 
controller can be used for transmitting program change messages to receiving devices. 


It is not often that the exact same tones are in the transmitting and receiving instruments, so some care 
must be taken when assigning tones to a given tone number. The ability to reassign programs to a given 
program change number should be part of an instrument's capabilities. Some instruments number their 
internal patches in octal numerics. This should have no effect on the numbers used for patch change. 
Numbering should begin with 00H and increment sequentially. For example, octal 11 would be 00H, 12 
would be 01H, etc. 
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It may not always be desirable for a tone change in a transmitting instrument to cause a program 
change in a receiving instrument. Some means of disabling the sending or reception of program change 
should be provided. Program change messages do not necessarily need to change tones. In some 
instruments, such as a drum machine, the message may be used to switch to a different rhythmic 
pattern. In MIDI controlled effects devices, the program change message may be used to select a 
different preset effect. 


Note: also see Bank Select. 


PITCH BEND CHANGE 


This function is a special purpose pitch change controller, and messages are always sent with 14 bit 
resolution (2 bytes). In contrast to other MIDI functions, which may send either the LSB or MSB, the 
Pitch Bender message is always transmitted with both data bytes. This takes into account human 
hearing which is particularly sensitive to pitch changes. The Pitch Bend Change message consists of 3 
bytes when the leading status byte is also transmitted. The maximum negative swing is achieved with 
data byte values of 00, 00. The center (no effect) position is achieved with data byte values of 00, 64 
(00H, 40H). The maximum positive swing is achieved with data byte values of 127, 127 (7FH, 7FH). 


Sensitivity of Pitch Bend Change is selected in the receiver. It can also be set by the receiver or 
transmitted via Registered Parameter number 00 00. 


AFTERTOUCH 


Two types of Aftertouch messages are available: one that affects an entire MIDI channel and one that 
affects each individual note played. They are differentiated by their status byte. In either case, the 
Aftertouch value is determined by horizontally moving the key (front-to-rear or left-to-right), or by 
pressing down on the key after it "bottoms out". Devices such as wind controllers can send Aftertouch 
from increasing breath pressure after the initial attack. The type of tone modification created by the 
Aftertouch is determined by the receiver. Aftertouch may be assigned to affect volume, timbre, vibrato, 
etc. 


If a "Channel Pressure" (Dn, Ovvvvvvv) message is sent, then the Aftertouch will affect all notes playing 
in that channel. 


If a "Polyphonic Key Pressure" (An, 0kkkkkkk, Ovvvvvvv) message is sent discrete Aftertouch is applied 
to each note (Okkkkkkk) individually. 


MIDI 1.0 Detailed Specification 4.2.1 19 


CHANNEL MODE MESSAGES 





(Control Change Status) BnH 
All Sound Off 120 
Reset All Controllers 121 
Local Control 122 
All Notes Off 128 
Omni Off 124 
Omni On 125 
Mono On (Poly Off) 126 
Poly On (Mono Off) 127 





A Mode message is sent with the same Status Byte as a Control Change message. The second byte of the 
message will be between 121 (79H) and 127 (7FH) to signify a mode message. Mode messages determine 
how an instrument will receive all subsequent voice messages. This includes whether the receiver will 
play notes monophonically or polyphonically and whether it will respond only to data sent on one 
specific voice channel or all of them. 


MODE MESSAGES AS ALL NOTES OFF MESSAGES 


Messages 123 through 127 also function as All Notes Off messages. They will turn off all voices 
controlled by the assigned Basic Channel. These messages should not be sent periodically, but only for a 
specific purpose. In no case should they be used in lieu of Note-Off commands to turn off notes which 
have been previously turned on. Any All Notes Off command (123-127) may be ignored by a receiver 
with no possibility of notes staying on, since any Note-On command must have a corresponding specific 
Note-Off command. 


THE BASIC CHANNEL OF AN INSTRUMENT 


Mode messages are recognized only when sent on the Basic Channel to which the receiver is assigned, 
regardless of the current mode. The Basic Channel is set in the transmitter or receiver either by 
permanent "hard wiring," by panel controls, or by System Exclusive messages, and cannot be changed by 
any MIDI mode or voice message. Mode messages can only be transmitted and received on an 
instrument's Basic Channel. 


RECEIVER'S MODE (OMNI ON/OFF & POLY/MONO) 


The receiver can be set to any of four modes which determine how it will recognize voice messages. The 
four modes are set with two mode messages: Omni On/Off, and Poly/Mono. 


Mode 1: Omni On, Poly 
Mode 2: Omni On, Mono 
Mode 3: Omni Off, Poly 
Mode 4: Omni Off, Mono 
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Mono and Poly determine how the receiver's voices will be assigned when more than one note is received 
simultaneously. In Mono mode, each voice in the receiver will respond monophonically to note messages 
on a particular MIDI channel. This would be like having several Monophonic synthesizers in a single 
box. In Poly mode, voices in the receiver will respond to note messages polyphonically. 


These four modes may be changed by panel controls on the receiver. Care must be taken, however, since 
it is possible that the receiver may be "disabled" by setting it to a mode where it will not recognize or 
correctly respond to data received from a transmitter. As the receiver has no way of knowing the mode of 
the transmitter, there is no guarantee that a receiver will interpret messages as expected if it has been 
manually set to a different mode. 


The recommended start up condition is Omni Mode On. This allows two instruments to be connected and 
played immediately without concern for selecting the instruments' basic channel. The receiver will 
respond to voice messages on all MIDI channels. With Omni off, a receiver would only respond to the 
voice messages on the Basic Channel to which it is set. 


Voice Message Paths with Poly/Mono and Omni On/Off Mode Selections: 







MIDI In 


ChannelNum.1 2 3 4 56 78 9101112131415 1 
MN SMe al ella Who 1 a a [Ollie 


Basic Channel Assigner 
Select "Switch" H 


(Shown @ Channel 1) 


Mefon O Poly Voice 
Omni "Switch" Poly/Mono "Switch" Assigner 


(Shown in Omni On Mode) (Shown in Poly Mode) 


When the receiver is in Poly mode and more than one note is received on the recognized channel(s), 
those notes will be played simultaneously to the limit of the receiver's number of voices. The 
recognizable channel(s) refers to all MIDI channels when Omni is On, or to only the receiver's Basic 
Channel when Omni is Off. 


When the receiver is in Mono mode, notes are assigned differently depending on whether Omni mode is 
On or Off. 


MONO MODE 


Mono mode is particularly useful for receiving MIDI data from guitar controllers, but can be used with 
keyboards and other controller devices as well. It is useful for such purposes as independent pitch 
bending of individual notes, portamento at specific rates between two notes, or transposition effects. 
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One of the reasons to use Mono mode is so that a receiver may respond in legato fashion to incoming 
note messages. If a Note-On is received, and then a second Note-On received without the first Note-Off 
being received, then the receiving instrument should change pitch to the new note, but not restart the 
envelopes (they should continue as if the same note was still being held). For a transmitter wishing a 
receiver to respond in legato fashion, the timing of the note messages would be like this: 


<Note-On #1> <Note-On #2> <Note-Off #1>, etc. 


MIDI rules still apply - a Note-Off must eventually be sent for every note. Also see Legato Mode. 


OMNI-OFF/MONO 


The third byte of a Mono Message specifies the number of channels in which Monophonic Voice 
messages are to be sent. If the letter M represents the number of acceptable MIDI channels, which may 
range from 1 to 16, and the letter N represents the basic channel number (1-16), then the channel(s) 
being used will be the current Basic Channel (N) through N+M-1 up to a maximum of 16. M=0 is a 
special case directing the receiver to assign all its voices, one per channel, from the Basic Channel N 
through 16. 


TRANSMITTER: When a transmitter set to Omni-Off/Mono mode, voice messages are sent 
on channels N through N+M-1. This means that each individual voice (or 
note) is sent on a single channel. The number of transmitted channels is 
limited to the number of voices in the transmitter. Additional notes will be 
ignored. When transmitting from a 16 voice instrument whose basic 
channel number N is set higher than 1, N+M-1 will be greater than 16 and 
notes assigned to nonexistent channels above 16 should not be sent. If full 
16 voice transmission is possible, the basic channel N should be set to 1. 
For example, a four-voice instrument set to a basic channel of 3 would 
transmit note messages on channels 38, 4, 5 and 6. 


RECEIVER: In a receiver set to Omni-Off/Mono mode, the voice messages received in 
channels N through N+M-1 are assigned monophonically to its internal 
voices 1 through M. If N=1, and M=16 (maximum), then the messages are 
received on Channels 1 through 16. Should more than one Note-On 
message be sent for a given channel, the receivers response is not specified. 
Only one note (or voice) can be assigned to a given MIDI channel in this 
mode. M=0 is a special case directing the receiver to assign its voices, one 
per channel, from the basic channel N through 16, until all available voices 
are used. 


OMNI-ON/MONO 


When a transmitter is set to Omni-On/Mono mode, voice messages for a single voice are sent on 
channels N. If a receiver is set to Omni-On/Mono mode, then voice messages received from any voice 
channel will control a single voice monophonically. Regardless of the number of MIDI channels being 
received or the polyphony on any of them, the receiver will only play one note at a time. 


TRANSMITTER: A transmitter may send a Mono message to put a receiver into Mono mode. 
However, since a receiver may not be capable of Mono mode, the 
transmitter may continue to send note messages polyphonically. Even if 
the transmitter and receiver are both playing monophonically, multiple 
Note-On messages can be sent . 
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RECEIVER: When a Note-On message is sent in the Omni-On/Mono mode, the receiver 
will play that note regardless of channel number. If the value of M is 2 or 
greater when receiving a Mono On message and Omniis on, M is ignored 
and the receiver will still be monophonic. When Omni is on, it is 
inappropriate to send a Mono message with M greater than 1. 


If a particular channel mode is not available on a receiver, it may ignore the message, or it may switch 
to an alternate mode (usually mode 1, which is Omni On/Poly). 


MODES NOT IMPLEMENTED IN A RECEIVER 


A transmitter could possibly request a mode not implemented in a receiver. For example, a transmitter 
might request Omni-Off Mono with M=2, but the receiver has only Omni-On Mono or Omni-On Poly 
capability. In this situation the receiver could do one of two things: (1) It can ignore the request, and no 
notes will sound; or (2) it can change to Omni-On Poly, and notes from both channels will play. The 
latter choice is recommended so that the receiver will respond to notes from the different channels. 


MONO POLY 
M=1 M1 
use use 


There is no way for a transmitter to know if a receiver has responded correctly to a particular Mode 
message. By implementing the response outlined above, unexpected results will be minimized. If it is 
possible for a receiver to ignore continuous controllers, it should do so in order that pitch bend or 
modulation intended for a single voice will not affect all the voices in the receiver. 











If Receiver does 

not have Mode 4, it 

can disregard messages, 
or act as shown here 


A transmitter may send Omni On or Omni Off messages and Poly or Mono messages in any order. A 
receiver should set individual flags indicating Omni On/Off and Poly/Mono. 


A receiver unable to accommodate a mode message such as Omni-Off Mono may switch to an alternate 
mode such as Omni-On Poly. If an Omni-Off message is then received, the receiver should not change to 
Omn1i-Off unless a Poly message is also received. 


It is acceptable to repeat either of the Omni On/Off or Poly/Mono messages when changing modes. For 
example, if a transmitter sends Omni Off Poly and later sends Omni On Poly, the retransmission of the 
"Poly" message should cause no problem. If a receiver cannot accommodate an Omni-Off Mono mode 
change from a transmitter, it should switch to an alternate mode such as Omni-On Poly as outlined 
above. 
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Receive Mode Messages—— 


Omni Omni 
Off Mono Off Poly 
Omni Flag On = 1 | fon] | 
Off =0 Sa =|, 








Mono/PolyMono = 
Flag Poly = 


y 


(Power-Up Status Receiver Unit Changes _ Receiver Changes 
Switches to to Omni-On/Poly to Omni-Off/Poly 
Omni-Off (Mode 1) (Mode 3) 


Receive Mode Messages 
Power Up [ Omni-Of Omni-Of 
OMNI 1 0 0 
MONO/POL 0 1 1 
Receive Modes 
Receive Mode Omni-On, Poly)(No Change) 


OMNI-ON = 1, OMNI-OFF = 0 N/A = A Mode Which is not Implemented in the Rec 
MONO = 1, POLY = 0 


ALL NOTES OFF 


All Notes Off (123) is a mode message which provides an efficient method of turning off all voices turned 
on via MIDI. While this message is useful for some applications, there is no requirement that a receiver 
recognize it. Since recognition of All Notes Off is not required of the receiver, all notes should first be 
turned off by transmitting individual Note-Off messages prior to sending an All Notes Off. 


In a MIDI keyboard instrument, notes turned on via the local keyboard should be differentiated from 
notes turned on via MIDI In. 


MIDI Out MIDI In MIDI Thru 





(Optional) 


Es) 
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In an instrument structured as shown above, it is possible that the instrument may not differentiate 
between MIDI In and the local keyboard commands. If an All Notes Off is received via MIDI, then a// 
notes will be turned off, including those being played on the instrument's own keyboard. This is not 
correct implementation of the All Notes Off message. All Notes Off should only turn off those notes that 
were turned on via MIDI. If an instrument cannot differentiate between its local keyboard and incoming 
MIDI messages, All Notes Off should be ignored. 


Receivers should ignore an All Notes Off message while Omni is on (Modes 1 & 2). For example, if a 
receiver gets an All Notes Off from a sequencer that inserts such messages whenever all keys are 
released on a track, and two tracks were recorded on such a sequencer (even on different MIDI 
channels), the All Notes Off message would cut off sustaining notes recorded on the other track. 





While MIDI devices should be able to respond to the All Notes Off message, an All Notes Off message 
should not be sent periodically as part of normal operation. This message should only be used to indicate 
that the entire MIDI system is "at rest" (i.e. when a sequence has stopped). However, a receiver should 
respond to an All Notes Off (unless Omni is on) whenever it is received, even when the system is not "at 
rest". 


Although other mode messages will turn off all notes, they should not be used as a substitute for the All 
Notes Off message when desiring to turn off all notes. When the receiver is set to Omni-Off Poly mode 
(Mode 3), All Notes Off will cancel Note-On messages on the basic channel only. When a receiver is set to 
Omni-Off Mono mode (Mode 4), All Notes Off should only cancel Note-On messages on the channel over 
which the message was received. 


Note: See more on All Notes Off in the Additional Explanations and Application Notes. 


ALL SOUND OFF 


All Sound Off (120) is a mode message intended to silence all notes currently sounding by instruments 
receiving on a specific MIDI channel. Upon reception, all notes currently on are turned off and their 
volume envelopes are set to zero as soon as possible. 


This message is not a replacement for the All Notes Off message, Note-Off messages, Hold Off, or Master 
Volume Off. The correct procedure of sending a Note-Off for each and every Note-On must still be 
followed. 


Although originally intended for silencing notes on a MIDI sound module, the All Sound Off message 
may be used to turn off all lights at a MIDI-controlled lighting console or to silence and clear the audio 
buffer of a MIDI-controlled reverb of digital delay. 


RESET ALL CONTROLLERS 


When a device receives the Reset All Controllers message (121), it should reset the condition of all its 
controllers (continuous and switch controllers, pitch bend, and pressures) to what it considers an ideal 
initial state (Mod wheel to 0, Pitch Bend to center, etc.). Reception follows the same rules as All Notes 


Off — Ignore if Omni is On . 


Sequencers that wish to implement Reset All Controllers, but want to accommodate devices that do not 
implement this command, should send what they believe to be the initial state of all controllers first, 
followed by this message. Devices that respond to this message will end up in their preferred state, 
while those that do not will still be in the sequencer's chosen initialized state. 
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LOCAL CONTROL 


Channel Mode Message 122, Local Control, is used to interrupt the internal control path between the 
keyboard and the sound-generating circuitry of a MIDI synthesizer. If 0 (Local Off ) is received the path 
is disconnected, keyboard data goes only to MIDI Out and the sound-generating circuitry is controlled 
only by incoming MIDI data. If a 7FH (Local On) is received, normal operation is restored. Local Control 
should be switchable from an instrument's front panel. 


When a keyboard instrument is being used as a receiving device via MIDI, it may be desirable to dis- 
connect the instrument's keyboard from its internal synthesizer so that local performance cannot 
interfere with incoming data. This may also save scanning time and thus speed up response to MIDI 
information. 

Instruments should power-up in Local On mode. An instrument should continue to send MIDI 
information from its keyboard while in Local Off. 
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SYSTEM COMMON MESSAGES 





MIDI Time Code Quarter Frame F1H 
Song Position Pointer F2H 
Song Select F3H 
Tune Request F6H 
EOX (End of Exclusive) F7H 





MTC QUARTER FRAME 


For device synchronization, MIDI Time Code uses two basic types of messages, described as Quarter 
Frame and Full. There is also a third, optional message for encoding SMPTE user bits. The Quarter 
Frame message communicates the Frame, Seconds, Minutes and Hours Count in an 8-message 
sequence. There is also an MTC FULL FRAME message which is a MIDI System Exclusive Message. 


See the separate MTC specification document for complete details. 


SONG POSITION POINTER 


A sequencer's Song Position (SP) is the number of MIDI beats (1 beat = 6 MIDI clocks) that have 
elapsed from the start of the song and is used to begin playback of a sequence from a position other than 
the beginning of the song. It is normally set to 0 when the START button is pressed to start sequence 
playback from the very beginning. It is incremented every sixth MIDI clock until STOP is pressed. If 
CONTINUE is pressed, it continues to increment from its current value. The current Song Position can 
be communicated via the Song Position Pointer message and can be changed in a receiver by an 
incoming Song Position Pointer message. This message should only be recognized if the receiver is set to 
MIDI sync (external) mode. 


Song Position Pointer is always multiplied by 6 times the MIDI clocks (F8H). Thus the smallest Song 
Position change is 6 MIDI clocks, or 1/16 note. The result is then multiplied by the internal time base of 
the sequencer. Here is an example: 

If Song Position Pointer = 10 

Multiply this times 6 MIDI clocks (10 X 6 = 60) 


Multiply the result (60) times the sequencer time base. If the time base is 96 clocks per 
beat, there are four internal clocks between each F8 so the result is 240 (60 X 4 = 240) 


Set internal pointers to begin playback 240 clock tics into the sequence. 
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Internal Computation: 


40(sp) x 6(cik) x 4(int) = 240 Wait for ‘continue’ Start 
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MIDI Clocks 
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Sequence | 
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Internal Clocks 
Start Synched Sequence Stop Sequence Start by 
‘Continue’ 
Count up Internal Clock to Command 


240 clock position and wait 
to receive ‘FB’ Command. 


NOTES 
1. This example assumes an internal clock rate of 96 internal 
clocks per quarter note. 


2. The time delay intervals ‘Ta’ and ‘t’ are time lags due to 
internal computations and are kept to a minimum. 





The Start message (FAH), is treated by MIDI as if it were a command comprised of a Song Position 
Pointer value of 0 plus a continue message (FBH). 


Since the Start message and the Continue message can be received while the sequencer has been 
stopped by a Stop message (FCH), the sequencer should be able to start quickly in response to a Start 
message, even if the sequencer is in the middle of a song. 


Song Position Pointer messages should be ignored if the instrument is not in MIDI sync mode (see 
System Real Time messages section for details on MIDI sync). 


RECOMMENDED USE OF SONG POSITION POINTER 


Previously it was recommended that a device wait 5 seconds after transmitting a Song Position Pointer 
message before it transmitted a Continue message and resumed sending MIDI Clocks. However, it is 
now recommended that any device receiving a Song Position Pointer (SPP) message be able to correctly 
receive a Continue message and subsequent MIDI Clocks while it is in the process of locating to the new 
position in the song. Upon locating to the new position the device must then play in sync with the device 
transmitting the SPP. 


For example, if the transmitter sends an SPP message with a value of 4 (24 MIDI Clocks), and while 
locating receives a Continue as well as an additional 3 MIDI Clocks, the receiving device should begin 


from the 27th clock in the song. 
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SONG SELECT 


Specifies which song or sequence is to be played upon receipt of a Start message in sequencers and drum 
machines capable of holding multiple songs or sequences. This message should be ignored if the receiver 
is not set to respond to incoming Real Time messages (MIDI Sync). 


RECEPTION OF SONG POSITION AND SONG SELECT 


When a device receives and recognizes a Song Position or Song Select message, it can take a relatively 
long time to implement the command. The receiver must continue to accept MIDI clocks after a Start 
has been received, and increment its Song Position while it is computing and locating to the correct 
address in memory for playback. For example, if a Song Position Pointer message is received which 
contains a value of 4 (24 MIDI Clocks), and during the process of locating a Continue and 3 clocks are 
received, the device should start playing from the point in its internal sequence corresponding to the 
27th clock. If a Timing Clock message is missed while the receiver is dealing with Song Position, the 
receiver may not synchronize correctly. Song Position or Song Select messages may only be sent when 
the system is not playing. 








TUNE REQUEST 


Used with analog synthesizers to request that all oscillators be tuned. 


KOX 


Used as a flag to indicate the end of a System Exclusive transmission. A System Exclusive message 
starts with FOH and can continue for any number of bytes. The receiver will continue to wait for data 
until an EOX message (F7H) or any other non-Real Time status byte is received. 


To avoid hanging a system, a transmitter should send a status byte immediately after the end of an 
Exclusive transmission so the receiver can return to normal operation. Although any Status Byte (except 
Real-Time) will end an exclusive message, an EOX should always be sent at the end of a System 
Exclusive message. Real time messages may be inserted between data bytes of an Exclusive message in 
order to maintain synchronization, and can not be used to terminate an exclusive message. 
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SYSTEM REAL TIME MESSAGES 





Timing Clock F8H 
Start FAH 
Continue FBH 
Stop FCH 
Active Sensing FEH 
System Reset FFH 





System Real Time messages are used to synchronize clock-based MIDI equipment. These messages 
serve as uniform timing information and do not have channel numbers. 


Real Time messages can be sent at any time and may be inserted anywhere in a MIDI data stream, 
including between Status and Data bytes of any other MIDI messages. Giving Real-Time messages high 
priority allows synchronization to be maintained while other operations are being carried out. 


As most keyboard instruments do not have any use for Real-Time messages, such instruments should 
ignore them. It is especially important that Real-Time messages do not interrupt or affect the Running 
Status buffer. A Real-Time message should not be interpreted by a receiver as a new status. 


TIMING CLOCK: Clock-based MIDI systems are synchronized with this message, which is 
sent at a rate of 24 per quarter note. If Timing Clocks (F8H) are sent during 
idle time they should be sent at the current tempo setting of the transmitter 
even while it is not playing. Receivers which are synchronized to incoming 
Real Time messages (MIDI Sync mode) can thus phase lock their internal 
clocks while waiting for a Start (FAH) or Continue (FBH) command. 


START: Start (FAH) is sent when a PLAY button on the master (sequencer or drum 
machine) is pressed. This message commands all receivers which are 
synchronized to incoming Real Time messages (MIDI Sync mode) to start 
at the beginning of the song or sequence. 


CONTINUE: Continue (FBH) is sent when a CONTINUE button is hit. A sequence will 
continue from its current location upon receipt of the next Timing Clock 
(F8H). 

STOP: Stop (FCH) is sent when a STOP button is hit. Playback in a receiver should 


stop immediately. 


START OR CONTINUE MESSAGES 


When a receiver is synchronized to incoming Real Time messages (MIDI Sync mode), the receipt of a 
Start (FAH) or Continue (FBH) message does not start the sequence until the next Timing Clock (F8H) 
is received. The FA and F8 should be sent with at least 1 millisecond time between them so the receiver 
has time to respond. However, a receiver should be able to respond immediately to the first F8H after 
receiving the Start or Continue. 
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FA F8 F8 


ee 


Neither the transmitter 
nor the receiver advances 
during this interval 


When the receiver is operating off of its internal clock it may ignore all Start, Stop and Continue 
messages or it may respond to these messages and start, stop or continue playing according to its own 
internal clock when these messages are received over MIDI. This decision is left up to the designer. 


STOP MESSAGE 


When a sequencer is stopped it should send out the Stop message (FCH) immediately, so that any 
synchronized devices will also stop. The sequencer's internal location should be set as it was in when 
Stop was sent. This way, if Continue is pressed, all instruments connected to the master will continue 
from the same point in the song without need for a Song Position Pointer message. 


Upon receiving a Stop message (FCH), a receiver should stop playing and not increment its Song 
Position when subsequent Timing Clock messages are received. The current Song Position should be 
maintained in the event that a Continue is received and the sequence is continued from the point that it 
was stopped. If a Song Position Pointer message is received, the device should change its internal Song 
Position and prepare to begin playback from the new location. 


If any Note-Off messages have not been sent for corresponding Note-Ons sent before Stop was pressed, 
the transmitter should send the correct Note-Off messages to shut off those notes. An All Notes Off 
message can also be sent, but this should not be sent in lieu of the corresponding Note-Off messages as 
not every instrument responds to the All Notes Off message. In addition to note events, any controllers 
not in their initialized position (pitch wheels, sustain pedal, etc.) should be returned to their normal 
positions. 


The following illustration shows a method to keep correct synchronization. These examples use an 
internal timebase of 96 pulses per 1/4 note, or 4 internal clocks per MIDI clock (F8H). 


MIDI In FA F8 F8 FC F8 
Internal 

Seq. 0 1 2 60 |61 |62 |63 |Stop 
ae FA F8——____ FC —__—_. F8 

: at any time here 

MIDI In FB F8 F8 

Internal 

Seq. 64 |65 {66 {67 6s {69 {70 

MIDI 

Out FB F8 F8 
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RELATIONSHIP BETWEEN CLOCKS AND COMMANDS 


A sequencer may echo incoming timing and voice information out the MIDI Out port while playing its 
own sequenced parts. System Real Time messages should always be given time priority when the data is 
merged in this manner. To accomplish this, it is permissible to change the actual order of bytes to 
accommodate Real Time messages. However, all Real Time bytes (F8H, FAH, FBH, FCH) must be sent 
in the order in which they are received. 


In the example below, a Note-On message is delayed slightly in order to give a priority to sending an 


F8H. 


Note On 
MIDIIn F8 F8 F8 |F8 F8 £8 F8 





MIDI Out F8 F8 F8| F8y F8 F8 F8 
Note On 


In order to avoid displacing clock messages in time, in addition to reversing their order with a voice 
message (as shown above), they may be also be inserted between the bytes of voice, common, or other 
messages. At no time should either an incoming clock byte or any voice message be dropped, but their 
order can be changed to accommodate the need for accurate timing. 


A sequencer may continue sending timing clock (F8H) while it is stopped. The advantage of this is that a 
synchronized device can know the starting tempo of a sequence just as the Start command is received. 


PRIORITY OF COMMANDS 


Redundant commands, such as receiving a Stop command while already stopped, or a Start or Continue 
command while already playing, should simply be ignored. 


If a clock based device receives commands both from its front panel and via its MIDI In, priority should 
be given to the most recently received command. However, it is also acceptable for a device to ignore 
either its front panel or incoming Real Time commands depending on its current operating mode. For 
example, a device set to respond to incoming MIDI clocks and Real Time commands may ignore the 
commands received from its front panel. It may also ignore incoming Real Time commands while set to 
operate with its internal clock. 


ACTIVE SENSING 


Use of Active Sensing is optional for either receivers or transmitters. This byte (FE) is sent every 300 ms 
(maximum) whenever there is no other MIDI data being transmitted. If a device never receives Active 
Sensing it should operate normally. However, once the receiver recognizes Active Sensing (FE), it then 
will expect to get a message of some kind every 300 milliseconds. If no messages are received within this 
time period the receiver will assume the MIDI cable has been disconnected for some reason and should 
turn off all voices and return to normal operation. It is reeommended that transmitters transmit Active 
Sensing within 270ms and receivers judge at over 330ms leaving a margin of roughly 10%. 
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The following flowchart shows the correct method of implementing Active Sensing: 


MIDI 
Reception Timer 
Interrupt Interrupt 


Turn All 
Notes Off 





Clear Timer 


Z#FE 






FE 
Set Flag 






To 
Other 
Operaton 





O Exit 


SYSTEM RESET 


System Reset commands all devices in a system to return to their initialized, power-up condition. This 
message should be used sparingly, and should typically be sent by manual control only. It should not be 
sent automatically upon power-up and under no condition should this message be echoed. 


If System Reset is recognized, the following operations should be carried out: 


1) Set Omni On, Poly mode (Gf implemented) 

2) Set Local On 

3) Turn Voices Off 

4) Reset all controllers 

4) Set Song Position to 0 

5) Stop playback 

6) Clear Running Status 

7) Reset the instrument to its power-up condition 
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SYSTEM EXCLUSIVE MESSAGES 


System Exclusive FOH 








System messages are not assigned to any particular MIDI channel. Thus, they will be recognized by 
MIDI receivers regardless of the basic channel to which they are set. System Exclusive messages, 
however, have a different purpose. Each instrument's System Exclusive messages (hereafter abbreviated 
as "Exclusive" messages) have their own special format according to an assigned manufacturer's ID 
number. 


Exclusive messages are used to send data such as patch parameters, sampler data, or a sequencer 
memory bulk dump. A format which is appropriate to the particular type of transmitter and receiver is 
required. For example, an Exclusive message which sets the feedback level for an operator in an FM 
digital synthesizer will have no corresponding or meaningful function in an analog synthesizer. 


Since the purpose of MIDI is to connect many kinds of musical instruments and peripheral equipment, it 
is best not to use Exclusive messages to convey real-time performance information (with the exception of 
special Universal messages described below). Performance information is best sent via Channel Voice 
messages in real time. Receivers should ignore non-universal Exclusive messages with ID numbers that 
do not correspond to their own ID. 


To avoid conflicts with non-compatible Exclusive messages, a specific ID number is granted to 
manufacturers of MIDI instruments by the MMA or JMSC. By agreement between the MMA and JMSC 
when an ID number is given, the Exclusive format which is used under that ID number must be 
published within one year. "Published", in this context, means not only utilizing the format, but also 
printing the information in the product's owner's manual and/or technical materials published by the 
manufacturer. This is consistent with one of the fundamental purposes of MIDI, which is to publicize 
information and foster compatibility. 


Any manufacturer of MIDI hardware or software may use the system exclusive codes of any existing 
product without the permission of the original manufacturer. However, they may not modify or extend it 
in any way that conflicts with the original specification published by the designer. Once published, an 
Exclusive format is treated like any other part of the instruments MIDI implementation — so long as 
the new instrument remains within the definitions of the published specification. 


Once an Exclusive format has been published, it should not be changed with the exception of bug fixes. 


If a new System Exclusive format is released, it should be published in the same manner as the first 
version. 


DISTRIBUTION OF ID NUMBERS 





American European Japanese Other Special 
1 byte ID: O01 - 1F 20 - 3F 40 - 5F 60 - 7C 7D - 7F 
3 byte ID: 00 00 O1 00 20 00 00 40 00 00 60 00 

00 1F 7F 00 3F TF 00 5F 7F 00 VF TF 


00 and 00 00 00 are not to be used. Special ID 7D is reserved for non-commercial use (e.g. schools, 
research, etc.) and is not to be used on any product released to the public. Since Non-Commercial codes 
would not be seen or used by an ordinary user, there is no standard format. Special IDs 7E and 7F are 
the Universal System Exclusive IDs.. 
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UNIVERSAL SYSTEM EXCLUSIVE 





System Exclusive ID numbers 7£ (Non-Real Time) and 7F (Real Time) are Universal Exclusive IDs, 
used for extensions to the MIDI specification. The standardized format for both Real Time and Non-Real 
Time Universal Exclusive messages is as follows: 


FOH <ID number> <device ID> <sub-ID#1> <sub-ID#2> . . . FU7H 


The <device ID> and <sub-ID#1> <sub-ID#2> fields are described in context below. A complete 
listing of the assigned Real time and Non-Real Time messages is given in TABLE VIIa. 


DEVICE ID 


Since System Exclusive messages are not assigned to a MIDI Channel, the Device ID (formerly referred 
to as the "channel" byte) is intended to indicate which device in the system is supposed to respond. The 
device ID 7F, sometimes referred to as the ‘all call’ device ID, is used to indicate that all devices should 
respond. 


In most cases, the Device ID should refer to the physical device being addressed (the "hunk of metal and 
plastic" is a common term that has been used), as opposed to having the same meaning as channel or 
referring to a virtual device inside a physical device. For reference, this also corresponds to old USI 
discussions that included a "Unit ID" that was supposed to be attached to one UART and set of in/out 
ports. 


However, there are exceptions - for example, what Device ID to use for a dual-transport tape deck and 
MMC commands? Some may feel more comfortable thinking of the Device ID as an "address" and allow 
for the possibility that a single physical unit may be powerful enough to have more than one valid 
address. (This also has more relevance as devices move from stand-alone units to cards in a computer.) 


Therefore, Device ID is meant to refer to a single physical device or I/O port as a default. Sophisticated 
devices - such as multi-transport tape decks, computers with card slots, or even networks of devices - 
may have more than one Device ID, and such occurrences should be explained to the user clearly in the 
manual. From one to sixteen virtual devices may be accessed at each Device ID by use of the normal 
MIDI channel numbers, depending on the capabilities of the device. 


SAMPLE DUMP STANDARD 


A standard has been developed for sampler data dumps. It has been designed to work as an open or 
closed loop system. The closed loop system implements handshaking to improve speed and error 
recovery. This also accommodates machines that may need more time to process incoming data. The 
open loop system may be desired by those wishing to implement a simplified version with no 
handshaking. 


Five of the basic messages are generic handshaking messages (ACK, NAK, Wait, Cancel & EOF), which 
are also used in other applications — for example File Dump. The remaining messages are Dump 
Request, Dump Header, Data Packets, and a Sample Dump Extensions message. The data formats are 
given in hexadecimal. 
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GENERIC HANDSHAKING MESSAGES 


ACK: 





FO 7E <device ID> 7F pp F7 
pp Packet number 


This is the first handshaking flag. It means "Last data packet was received correctly. Start sending 
the next one." The packet number represents the packet being acknowledged as correct. 


NAK: 








FO 7E <device ID> 7E pp F7 
pp Packet number 


This is the second handshaking flag. It means "Last data packet was received incorrectly. Please re- 
send." The packet number represents the packet being rejected. 


CANCEL: 





FO 7E <device ID> 7D pp F7 
pp Packet number 


This is the third handshaking flag. It means "Abort dump." The packet number represents the 
packet on which the abort takes place. 


WAIT: 





FO 7E <device ID> 7C pp F7 
pp Packet number 
This is the fourth handshaking flag. It means "Do not send any more packets until told to do 
otherwise." This is important for systems in which the receiver (such as a computer) may need to 
perform other operations (such as disk access) before receiving the remainder of the dump. An ACK 


will continue the dump while a Cancel will abort the dump. 


EOF: 





FO 7E <device ID> 7B pp F7 
pp packet number (ignored) 


This is a new generic handshaking flag which was added for the File Dump extension, and is 
described fully under the File Dump heading. 
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DUMP HEADER 


FO 7E <device ID> 01 ss ss ee ff ff ff gg gg gg hh hh hh ii ii ii jj FT 





ss ss Sample number (LSB first) 

ee Sample format # of significant bits from 8-28) 

Ce ae oh Sample period (1/sample rate) in nanoseconds (LSB first) 

gg gg gg Sample length in words (LSB first) 

hh hh hh Sustain loop start point word number (LSB first) 

ii Gi di Sustain loop end point word number (LSB first) 

43 Loop type (00 = forward only, 01 = backward/forward, 7F = Loop off) 
DUMP REQUEST 


FO 7E <device ID> 03 ss ss F7 





ss ss Requested sample, LSB first 


Upon receiving this message, the sampler should check to see if the requested sample number falls ina 
legal range. If it is, the requested sample becomes the current sound number and is dumped to the 
requesting master following the procedure outlined below. If it is not within a legal range, the message 
should be ignored. 


DATA PACKET 


FO 7E <device ID> 02 kk <120 bytes> 11 F7 





kk Running packet count (0-127) 
ll Checksum (XOR of 7E <device ID> 02 kk <120 bytes>) 


The total size of a data packet is 127 bytes. This is to prevent MIDI input buffer overflow in machines 


that may want to receive an entire message before processing it. 128 bytes, or 1/2 page of memory, is 
considered the smallest reasonable buffer for modern MIDI instruments. 


SAMPLE DUMP EXTENSIONS 


All future extensions to the Sample Dump Standard will appear under the Sub-ID#1 (05) of the 
Universal System Exclusive Non-Real Time message. 


MULTIPLE LOOP POINT MESSAGES: 

These messages were added as an extension to the Sample Dump Standard, allowing for the 
definition of up to 16,388 pairs of loop points per sample. This cures the shortcoming of the Sample 
Dump Standard allowing only 1 pair of loop points to be defined per sample. It also allows 


modification of loop points without also having to send the sample itself. 


The formats of these messages are as follows: 
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Loop Point Transmission (17 bytes): 





FO 7E <device ID> 05 01 ss ss bb bb cc dd dd dd ee ee ee F7 





FO 7E <device ID> Universal System Exclusive Non-Real Time header 
05 Sample Dump Extensions (sub-ID#1) 

01 Multiple Loop messages (sub-ID#2) 

ss ss Sample Number (LSB first) 

bb bb Loop number (LSB first; 7F 7F = delete all loops) 
ec Loop type 


00 = Forwards Only (unidirectional) 
01 = Backwards/Forwards (bi-directional) 


7F = Off 
dd dd dd Loop start address (in samples; LSB first) 
ee ee ee Loop end address (in samples; LSB first) 


F7 EOX 


Loop Points Request (10 bytes): 





FO 7E <device ID> 05 02 ss ss bb bb F7 





FO 7E <device ID> Universal System Exclusive Non-Real Time Header 
05 Sample Dump Extensions (sub-ID#1) 

02 Loop Points Request (sub-ID#2) 

ss ss Sample Number (LSB first) 

bb bb Loop Number (LSB first; 7F 7F = request all loops) 
F7 EOX 


One message is sent and one loop affected per loop request or transmission, with the obvious 
exceptions of ‘Delete All Loops' and 'Request All Loops'. If a Loop Message is sent with the same 
number as an existing loop, the new information replaces the old. Loop number 00 00 is the same as 
the sustain loop defined in the Sample Dump Standard. 
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SAMPLE DUMP TRANSMISSION SCENARIO 


Once a dump has been requested either from the front panel or over MIDI, the dump header is sent. 
After sending the header, the master must time out for at least two seconds, allowing the receiver to 
decide if it will accept the dump (enough memory, etc.). If the master receives a Cancel, it should abort 
the dump immediately. If it receives an ACK, it will start sending data packets. If it receives a Wait, it 
will pause indefinitely until another message is received. If nothing is received within the time-out, the 
master will assume an open loop and begin sending packets. 


A data packet consists of its own header, a packet number, 120 data bytes, a checksum, and an End Of 
Exclusive (EOX). The packet number starts at 00 and increments with each new packet, resetting to 00 
after it reaches 7FH. This is used by the receiver to distinguish between a new data packet and one 
being resent. This number is followed by 120 bytes of data which form 30, 40 or 60 words (MSB first) 
depending on the sample format. 


Each data byte consists of 7 bits. If the sample format is 8-14 bit, two bytes form a word. Sample formats 
of 15-21 bits require three bytes/word (yielding 40 words/packet). Sample formats of 22-28 bits require 
four bytes/word (yielding 30 words/packet). Information is left-justified within the 7-bit bytes and 
unused bits are filled in with zeros. For example, the sample word FFFH would be sent as 01111111B 
01111100B. The word FFFH represent a full positive value (000H represents full negative). The 
checksum is the XOR of 7E <device ID> 02 <packet number> <120 bytes>. 


When a sampler is receiving a data dump, it should keep a running checksum during reception. If the 
checksums match, it sends an ACK and wait for the next packet. If the checksums do not match, it sends 
a NAK and waits for the next packet. If the next packet number does not match the previous one and the 
sampler has no facility for receiving packets out of sequence, it should ignore the error and continue as if 
the checksum had matched. 


When a sampler is sending a data dump, it should send a packet and watch its MIDI In port. If an ACK 
is received, it sends the next packet. If a NAK is received and the packet number matches that of the 
previous packet, it re-sends that packet. If the packet numbers do not match and the sampler has no 
facility to send packets out of sequence, it should ignore the NAK. If a Wait is received, the sampler 
should watch its MIDI IN port indefinitely for another message and process it like a normal ACK, NAK, 
Cancel, or illegal message (which would usually abort the dump). If nothing is received within 20ms, the 
sampler can assume an open loop and send the next packet. 


The packet numbers are included in the handshaking flags (ACK, NAK, Cancel, Wait) in order to 
accommodate future machines that might have the intelligence to re-transmit specific packets out of 
sequence (i.e. after subsequent packets have been received). 


This process continues until there are less than 121 bytes to send. The final data packet will still consist 
of 120 data bytes regardless of how many significant bytes actually remain. The unused bytes will be 
filled out with zeros. The receiver should receive and handshake on the last packet. If the receiver's 
memory becomes full, it should send a Cancel to the master. 
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DEVICE INQUIRY 


The following two messages are used for device identification, and are categorized as Non-Real Time 
System Exclusive General Information messages (sub-ID#1 = 06). 


The format of the inquiry message is as follows: 


FO 7E <device ID> 06 01 F7 





FO 
06 
O01 
F7 





7E <device ID> 


Universal System Exclusive Non-real time header 
General Information (sub-ID#1) 

Identity Request (sub-ID#2) 

EOX 


A device which receives the above message would respond as follows: 


(Note that if <device ID>=7FH then the device should respond regardless of what <device ID> itis 


set to.) 





FO 7E <device ID> 06 02 mm ff ff dd dd ss ss ss ss F7 


FO 
06 
02 
mm. 
ff 
dd 
ss 
F7 





ff 
dd 
ss 


<device ID> 


ss ss 


Universal System Exclusive Non-real time header 
General Information (sub-ID#1) 

Identity Reply (sub-ID#2) 

Manufacturers System Exclusive id code 

Device family code (14 bits, LSB first) 

Device family member code (14 bits, LSB first) 
Software revision level. Format device specific 
EOX 


Note that if the manufacturers id code (mm) begins with 00H then the above message is extended by two 
bytes to handle the additional manufacturers id code. 
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FILE DUMP 


File Dump provides a protocol for transmitting files from one computer to another using MIDI. There 
are two primary motivations for this protocol: transmitting MIDI Files (especially tempo maps) between 
computers and small ROM/microcomputer-based “boxes”; and transmitting files of any type, including 
MIDI files, between two computers of different types. The filename is sent with the file, so that several 
files may be sent one after another with as little user interaction as necessary. 


All File Dump messages are Exclusive Non-Real Time messages (sub-ID#1 = 07), and begin with the 
following header: 


FO 7E <device ID> 07 <sub-ID#2> ss 





<device ID> device ID of message destination (7F is also acceptable here) 


07 File Dump (sub-ID#1) 
<sub-ID#2> file dump message type: 
01 Header 
02 Data Packet 
03 Request 
ss device ID of message source (7F “all-call” is NOT acceptable here) 


The source device ID is included so that it may be used by the receiver of this message in all packets 
which it sends back to the sender of this message. In other words, if the handshake of this transfer is 
between device A and device B, all messages going from A to B specify B as the destination of the 
message, and all messages going back from B to A specify A as the destination of the message. In order 
to do this, the first message to B must also specify A as the source of the first message, so that B knows 
the device ID of who to respond to for all response messages. 


REQUEST 





FO 7E <device ID> 07 03 ss <type> <NAME> F7 





<device ID> device ID of request destination (will become file sender) 


ss device ID of requester (will become file receiver) 
<type> four 7-bit ASCII bytes: type of file 
<NAME> filename: 7-bit ASCII bytes terminated by the message’s F7 





<type> describes what type of file, in a general sense, is being requested. Only the types shown below 
should be used; you should only use any other type if you know that the receiver will recognize it. If the 
device receiving a request doesn’t support the requested type, it should send the Cancel message 
described below. 





Recommended 
<type> DOS Extension _ Description 
MIDI MID It’s a MIDI File 
MIEX MEX It’s a MIDIEX File 
ESEQ ESQ It’s an ESEQ File 
TEXT TXT It’s a 7-bit ASCII Text File 
BIN<space> BIN It’s a binary file (such as any MS-DOS file) 
MAC<space> MAC It’s a Macintosh file (with MacBinary header) 


If <t ype> is MAC, this means a Macintosh file is being requested. Because Macintosh files contain two 
“forks,” and other important Finder information, they are sent as their MacBinary image. Note that 
programs wishing to transmit only MIDI Files, even on the Macintosh, won’t need to worry about 
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MacBinary, because MIDI Files must always use the MIDI designation to be universally recognized as 
MIDI Files. 


The filename may be any length, and may be omitted entirely. If it is omitted, it means “whatever is 
currently loaded.” The filename may contain only printable ASCII characters (20H through 7EH). 
Colons and backslashes may optionally be interpreted as path specifiers: these characters should be 
avoided in filenames if this behavior is not desired by the user. If the device receiving the request 
message does not have a file system, it should send whatever is currently loaded, using a null filename. 


If the device receiving the request message is a computer, it should initiate a transfer if it recognizes the 
filename, or if there is no filename but there is a “currently loaded” file. If these conditions aren’t met, it 
may either prompt the user for a valid filename (displaying the filename supplied in the dump message), 
or just send the Cancel message back to the requester. If the user is to be prompted, the Wait message 
should be sent to the requester so that it knows that it may be awhile before the transfer is initiated or a 
Cancel is to be sent. 


HEADER 








FO 7E <device ID> 07 01 ss <type> <length> <NAME> F7 


<device ID> device ID of requester/receiver 


ss device ID of sender 

<type> four 7-bit ASCII bytes: type of file 

<length> four 7-bit bytes: actual (un-encoded) file length, LSB first 
<NAME> filename: 7-bit ASCII bytes terminated by the message’s F7 





<type> and <NAME> are exactly as described in the Dump Request message. 


If the length of the file is not known (because it will be converted on the fly), zero may be sent as the 
length. 


If the sender is a small ROM-based “box” without files, it need not send a filename. If it is a computer, 
and there is a filename associated with it, it should be sent in the header. As described above, it may be 
any length, must only contain printable ASCII characters, and may contain path description characters. 
For maximum compatibility, no path information should be sent. DOS-like machines should send the file 
extension as part of the name, separated by a period, with no trailing spaces before the period. 


If the receiver is a computer, and if the program running supports receiving files, it should modify the 
filename if necessary to make it appropriate for its file system. For instance, if it is a DOS machine, and 
the given filename contains a period, it should interpret everything after the period as the file’s 
extension. If there is no period, it should use the appropriate extension listed above. If it is running 
interactively, it should prompt the user with the filename supplied in the dump message, so that the 
user can modify it if desired, if no name is sent, or if a file by that name already exists. If the user is to 
be prompted, the Wait message should be sent to the sender so that it knows that it may be awhile 
before the transfer is continued or a Cancel is sent. 


If the receiver is a small ROM-based “box” without files, or a program on a computer which only expects 


this protocol to replace the file currently in memory, it should simply ignore the filename and replace its 
current memory contents with the contents of the transmitted file, if the file is a supported type. 


DATA PACKET 





FO 7E <device ID> 07 02 <packet #> <byte count> <data> <chksm> F7 


<device ID> device ID of receiver 
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<packet #> one-byte packet count 


<byte count> one-byte packet size: number of encoded data bytes 
minus one 

<data> the data, encoded as described below 

<chksm> one-byte checksum (XOR of all bytes which 


follow FO up to the checksum byte, similar to 
sample dump) 


The total size of a data packet may be slightly larger than for sample dump: 1387 bytes maximum. 

The packet number starts at 00 and increments with each new packet, resetting to 00 after it reaches 
7FH. This is used by the receiver to detect missed packets. The byte count is the number of encoded data 
bytes minus one: for example, 64 stored bytes of the file are encoded in 74 transmitted bytes (as 
described below): the byte count would be 73. (Subtracting one allows sending 128 transmitted data 
bytes: one would never need to send zero bytes). 


Instead of nibblizing, which would double transmission time, the data is “7-bit-ized” so that the 
transmission time is more like 12% more than sending it as 8-bit (which isn’t possible over MIDI). Each 
group of seven stored bytes is transmitted as eight bytes. First, the sign bits of the seven bytes are sent, 
followed by the low-order 7 bits of each byte. (The reasoning is that this would make the auxiliary bytes 
appear in every 8th byte without exception, which would therefore be slightly easier for the receiver to 
decode.) The seven bytes: 





AAAAaaaa BBBBbbbb CCCCcccc DDDDdddd EEEFReeee FFFFff££ GGGGgggg 

















are sent as: 


OABCDEFG 
QAAAaaaa OBBBbbbb OCCCcccc ODDDdddd OEEEFeeee OFFFfff£ OGGGgggg 




















From a buffer to be encoded, complete groups of seven bytes are encoded into groups of eight bytes. If the 
buffer size is not a multiple of seven, there will be some number of bytes left over after the groups of 
seven are encoded. This short group is transmitted similarly, with the sign bits occupying the most 
significant bits of the first transmitted byte. For example: 


AAAAaaaa BBBBbbbb CCCCcccc 


are transmitted as: 


OABCO000 OAAAaaaa OBBBbbbb O0CCCcccc 


Since the maximum packet size is 128 transmitted bytes, this corresponds to sixteen groups of seven 
bytes, or 112 stored bytes. 
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HANDSHAKING FLAGS 


For handshaking messages, the same generic set originally created for Sample Dump Standard — plus a 
new EOF message — are to be used (Non-Real Time sub-ID#1 = 7B-7F). Since these first four message 
were explained in the Sample Dump section, only newly significant information will be presented here. 


FO 7E <device ID> <sub-ID#1> pp F7 





<device ID> device ID of packet sender (message destination) 
<sub-ID#1> handshake message: 





7B End of File 
TC Wait 
7D Cancel 
TE NAK 
TF ACK 
pp packet number 


NAK: 





FO 7] 





<device ID> 7E pp F7 


Gl 


<device ID> device ID of packet sender (ACK receiver) 
pp packet number 


This should be sent whenever the length of a message was wrong, or the checksum was incorrect. 
After receiving a NAK, the sender should resend the packet. After sending a NAK, the receiver 
should expect the same packet to be resent. If the same packet has an error three consecutive times, 
a Cancel should be sent instead of a NAK. If the packet number was wrong, such as if a packet (or a 
NAK) was missed, the Cancel message should be sent instead of a NAK. 


ACK: 


FO 7E <device ID> 7F pp F7 





<device ID> device ID of packet sender (ACK receiver) 
pp packet number 


The packet number represents the packet being acknowledged as correct. The packet number in the 
ACK responding to the Header is undefined. 


WAIT: 


FO JE <device ID> 7C pp F7 





<device ID> device ID of Wait receiver 
pp packet number (ignored) 


This handshaking flag is used after receiving a File Header, Data Packet, or File Dump Request. 
When responding to a Header it means “Do not send data packets until you receive an ACK (or a 
Cancel).” When responding to a data packet, it means “Do not send any more packets until you 
receive an ACK or NAK (or a Cancel).” When used in response to a File Dump Request, it means 
“Your File Header (or a Cancel) will follow soon — be patient.” 
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This message is important for systems in which the receiver may need to perform other operations, 
such as disk access or prompting the user, before processing the remainder of the dump. A slow 
device may in fact wish to transmit a Wait every time it receives a File Header, Data Packet, or File 
Dump Request, thus giving itself unlimited time in which to digest the received data and respond 
appropriately. 


CANCEL: 


FO 7E <device ID> 7D pp F7 





<device ID> device ID of Cancel receiver 
pp packet number (ignored) 


This handshaking flag may be used at any time. It means “Abort dump.” The packet number 
represents the packet on which the abort takes place, but is ignored by the receiver. This may be 
sent by either the sender or receiver when any error is detected, such as incorrect packet numbers in 
a data packet or a handshake message: or when a dump is canceled by the user. If the sender aborts 
a transmission, it should use the receiver’s device ID in the Cancel message (which it put in the 
header (<device ID>) in the first place). If the receiver aborts a transmission, it should use the 
sender’s device ID in the Cancel message (which the sender put in the header (ss)). ACK 


END OF FILE (EOF): 


FO 7E <device ID> 7B pp F7 





<device ID> device ID of receiver 
pp packet number (ignored) 


This is the fifth generic handshaking flag within MIDI, sub-ID#1 (7B). After sending the last packet 
of a lengthy message (such as File Dump), the sender must send an EOF message to inform the 
receiver that the entire file has been sent. This is critical if the length in the File Dump Header is 0 
(which means that the file length is unknown), because this is the only way the receiver can know 
the transmission is complete and correct. This message must be sent even if the correct length is 
known at the beginning. EOF requires no response from the receiver. 


FILE DUMP TRANSMISSION SCENARIO 


The File Dump Request is optional. A device may request a file (or memory contents), using the Request 
message, or a user may initiate a file dump without a request message being sent. Within 200 msec after 
receiving the Request message EOX (F7), the sender must respond with a File Dump header, Wait, or 
Cancel. If it responds with Wait, it may send a File Dump header or a Cancel message whenever it’s 
good and ready. 


The sender then sends a File Dump header message. Within 200 msec after receiving the Header EOX 
(F7), the receiver must respond with ACK, Wait, or Cancel. If it responds with Wait, it may send an 
ACK or a Cancel message whenever it’s good and ready. If the sender does not receive any message 
during this time, it assumes open loop transmission, and proceeds as if an ACK had been received. 


The sender then sends a data packet. As the receiver receives the data packet, it keeps a running 
checksum. If the checksums match, and it can deal with the data immediately, it sends an ACK and 
waits for the next packet. If it needs more than 50 msec to store the data, it sends a Wait message. 
(After storing the data, it then sends an ACK to continue the process). If the checksums do not match, or 
if the length is wrong, it sends a NAK and waits for the same packet to be resent. If the packet number 
is not the one it was expecting, it sends a Cancel message and ignores all further data packets until a 
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new header is sent (in the open-loop case, the sender won’t ever receive a Cancel message). If the 
receiver’s memory ever becomes full, even during the last packet, it should send a Cancel to the sender. 


When a device is sending a data dump, it should send a packet and watch its MIDI IN port. If an ACK is 
received, it should send the next packet immediately. If a NAK is received and the packet number 
matches that of the previous packet, it re-sends that packet. If the packet number of an ACK or a NAK 
do not match the number of the packet just sent, the sender should send a Cancel message, and abort 
the transmission. If a Wait is received, it should watch its MIDI IN port indefinitely for another 
message. If it receives an ACK or NAK, it should process it normally, and continue: if it receives a 
Cancel or an illegal message, it should abort the dump process. If nothing is received in 50 msec after a 
data packet or 200 msec after a header, it can assume an open loop and send the next packet. 


After the receiver ACKs the last packet, the sender transmits an EOF. No ACK is required for this 
message. The file dump is then complete. 


Any packet may contain any number of bytes, up to 128 encoded data bytes. Most devices probably will 


transmit several packets of equal size, and send what’s left over as a final packet. However, the receiver 
should never make any assumption about packet size. 
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MIDI TUNING 


This is an addition to the MIDI specification which allows the sharing of “microtunings” (user-defined 
scales other than 12-tone equal temperament) among instruments of different manufacture, and the 
switching of these tunings during real-time performance. 


The messages include: 


— bulk tuning dump request (non-real-time) 
— bulk tuning dump (non-real-time) 
— single-note tuning change (real-time) 


Even though the first two messages are in the Universal Non-Real Time area and the last in the Real 
Time area, they keep the same sub-IDs to more obviously group them and possibly ease the parsing of 
them. Single Note Retuning is a part of the proposal which allows retuning of individual MIDI note 
numbers to new frequencies in real time as a performance control. 


The standard does not attempt to dictate how a manufacturer implements microtuning, but provides a 
general means of sharing tuning data among different instruments. 


This goal does require shared assumptions which have some architectural implications. The standard 
requires that any of the 128 defined MIDI key numbers (or at least those MIDI key numbers covered by 
the instrument’s playable range) be tunable to any frequency within the proposed frequency range. The 
standard also strongly suggests, but does not enforce, an exponential (constant cents) rather than linear 
(constant Hertz) tuning resolution across the instrument’s frequency range. 


The standard permits the changing of tunings in real-time, both by the selection of presets and on a per- 
note basis. When a sounding note is affected by either real-time tuning message, the note should 
instantly be re-tuned to the new frequency while it continues to sound: this change should occur without 
glitching, forced Note-Offs, re-triggering or other audible artifacts (see section 4, “Additional”). 


The standard provides for 128 tuning memory locations (programs). As with the MIDI program change 
message, this is a maximum value. An instrument supporting the standard may have any lesser number 
of tuning programs. The standard requires only that all existing tuning programs respond to the 
messages as specified (See section 3, “Continuous Controller Messages”). 


Although directly applicable to some existing instruments, the standard attempts to define a coherent 
framework within which the designers of future instruments can profitably work. It is hoped that by 
providing this framework the standard will make microtunability more easily implemented and more 
common on MIDI instruments. 


FREQUENCY DATA FORMAT 


The frequency resolution of the standard should be stringent enough to satisfy most demands of music 
and experimentation. The standard provides resolution somewhat finer than one-hundredth of a cent. 
Instruments may support the standard without necessarily providing this resolution in their hardware: 
the standard simply permits the transfer of tuning data at any resolution up to this limit. 


Frequency data shall be sent via system exclusive messages. Because system exclusive data bytes have 
their high bit set low, containing 7 bits of data, a 3-byte (21-bit) frequency data word is used for 
specifying a frequency with the suggested resolution. An instrument which does not support the full 
suggested resolution may discard any unneeded lower bits on reception, but it is preferred where 
possible that full resolution be stored internally, for possible transmission to other instruments which 
can use the increased resolution. 
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Frequency data shall be defined in units which are fractions of a semitone. The frequency range starts at 
MIDI note 0, C = 8.1758 Hz, and extends above MIDI note 127, G = 12543.875 Hz. The first byte of the 
frequency data word specifies the nearest equal-tempered semitone below the frequency. The next two 
bytes (14 bits) specify the fraction of 100 cents above the semitone at which the frequency lies. Effective 
resolution = 100 cents / 2!4 = .0061 cents. 


One of these values ( 7F 7F 7F ) is reserved to indicate not frequency data but a “no change” condition. 
When an instrument receives these bytes as frequency data, it should make no change to its stored 
frequency data for that MIDI key number. This is to prevent instruments which do not use the full range 
of 128 MIDI key numbers from sending erroneous tuning data to instrument which do use the full range. 
The three-byte frequency representation may be interpreted as follows: 


Oxxxxxxx Oabcdefg Ohijkimn 


XXXXXXX = semitone 
abcdefghijkimn = fraction of semitone, in .0061-cent units 


Examples of frequency data: 


00 00 00 = 8.1758 Hz (C — normal tuning of MIDI key no. 0) 
00 00 01 = 8.2104 Hz 

01 00 00 = 8.6620 Hz 

OC 00 00 = 16.3516 Hz 

3c 00 00 = 261.6256 Hz (middle C) 

3D 00 00 = 277.1827 Hz (C#— normal tuning of MIDI key no. 61) 
42 7F 7F = 439.9984 Hz 

43 00 00 = 440.0000 Hz (A-440) 

43 00 01 = 440.0016 Hz 

78 00 00 =  8872.0190 Hz (C — normal tuning of MIDI key no. 120) 
78 00 01 = 8372.0630 Hz 


7F 00 00 = 12543.8800 Hz (G — normal tuning of MIDI key no. 127) 
7F 00 01 = 12543.9200 Hz 

TF 7F 7E = 18289.7300Hz (top of range) 

7F 7F 7F = no change (reserved) 





BULK TUNING DUMP REQUEST 


A bulk tuning dump request is as follows: 


FO 7E <device ID> 08 00 tt F7 








FO 7E Universal Non-Real Time SysEx header 
<device ID> ID of target device 

08 sub-ID#1 = MIDI Tuning Standard 

00 sub-ID#2 = 00H, bulk dump request) 

ee tuning program number (0 — 127) 

F7 EOX 


The receiving instrument shall respond by sending the bulk tuning dump message described in the 
following section for the tuning number addressed. 


BULK TUNING DUMP 
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A bulk tuning dump comprises frequency data in the 3-byte format outlined in section 1, for all 128 
MIDI key numbers, in order from note 0 (earliest sent) to note 127 (latest sent), enclosed by a system 
exclusive header and tail. This message is sent by the receiving instrument in response to a tuning 
dump request. 








FO 7E <device ID> 08 01 tt <tuning name> [xx yy zz] ... chksum F7 
FO 7E Universal Non-Real Time SysEx header 
<device ID> ID of responding device 
08 sub-ID#1 = MIDI Tuning Standard 
O1 sub-ID#2 = 01H, bulk dump reply) 
te tuning program number (0 — 127) 
<tuning name> 16 ASCII characters 
[xx yy zz] frequency data for one note (repeated 128 times) 
chksum checksum (XOR of 7E <device ID> 01 tt <388 bytes>) 
F7 EOX 


If an instrument does not use the full range of 128 MIDI key numbers, it may ignore data associated 
with un-playable notes on reception, but it is preferred where possible that the full 128-key tuning be 
stored internally, for possible transmission to other instruments which can use the increased resolution. 
On transmission, it may if necessary pad frequency data associated with un-playable notes with the “no 
change” frequency data word defined above. For keys in the instrument’s key range, the pitch that is 
sent should be the pitch that key would play if it were received as part of a note-on message. For keys 
outside the key range, 7F 7F 7F may be sent. 


SINGLE NOTE TUNING CHANGE (REAL-TIME) 


The single note tuning change message (Exclusive Real Time sub-ID#1 = 08) permits on-the-fly 
adjustments to any tuning stored in the instrument’s memory. These changes should take effect 
immediately, and should occur without audible artifacts if any affected notes are sounding when the 
message is received. 


FO 7F <device ID> 08 02 tt ll [kk xx yy zz] F7 


FO 7F Universal Real Time SysEx header 

<device ID> ID of target device 

08 sub-ID#1 (MIDI Tuning Standard ) 

02 sub-ID#2 (02H, note change) 

ca tuning program number (0 — 127) 

Te number of changes (1 change = 1 set of [kk xx yy zz]) 

[kk MIDI key number 

xx yy zzl frequency data for that key (repeated ‘Il’ number of times) 
F7 EOX 


This message also permits (but does not require) multiple changes to be embedded in one message, for 
the purpose of maximizing bandwidth. The number of changes following is indicated by the byte 11; the 
total length of the message equals 8 + (11 x 4) bytes. 


If an instrument does not support the full range of 128 MIDI key numbers, it should ignore data 
associated with un-playable notes on reception. 
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This message can be used to make changes in inactive (background) tunings as well. This message may 
also, at the discretion of the manufacturer, be transmitted by the instrument under particular 
circumstances (for example, while holding down one or more keys and pressing a “send-single-note- 
tuning” front panel button). 


CHANGING TUNING PROGRAMS 


A registered parameter number shall be allotted to select any of the instrument’s stored tunings as the 
“current” or active tuning. Instruments which permit the storage of multiple microtunings should 
respond to this message by instantly changing the “current” tuning to the specified stored tuning. This 
change takes effect immediately and must occur without audible artifacts (notes-off, resets, re-triggers, 
glitches, etc.) if any affected notes are sounding when the message is received. 


As with the MIDI program change message, no assumptions are made as to the underlying architecture 
of the instrument. For instance, in cases where layered or multi-timbral sounds might be assigned to 
different tunings, so that more than one tuning might be active, the manufacturer may decide how best 
to interpret this message. The basic channel number might prove useful in discriminating between 
multiple active tunings, or a certain range of tuning programs might be set aside and defined as active. 


The message is sent as a registered parameter number controller message, followed by either a data 
entry, data increment, or data decrement controller message, e.g. (with running status shown): 


Bn 64 03 65 00 06 tt (data entry) 

Bn 64 03 65 00 60 7F (data increment) 
Bn 64 03 65 00 61 7F (data decrement) 
n = basic channel number 

tt = Tuning Program number (1-128) 


Likewise, a Tuning Bank Change Registered Parameter number is also assigned as follows: 


Bn 64 04 65 00 06 tt (data entry) 

Bn 64 04 65 00 60 7F (data increment) 
Bn 64 04 65 00 61 7F (data decrement) 
n = basic channel number 

tt = Tuning Bank number (1-128) 


For maximum flexibility, this Bank Number is kept separate from the normal Program Change Bank 
Select (controller #00). However, an instrument may wish to link the two as a feature for the user, 
especially if a tuning bank is stored alongside a patch parameter bank (for example, on a RAM 
cartridge). 


If an instrument receives a Tuning Program or Bank number for which it has no Program or Bank, it 
should ignore that message. Standard mappings of “common” tunings to program numbers are not being 
proposed at this time. 


Additional 


There is some question as to whether instantaneous response to real-time tuning changes is desirable in 
every circumstance. In some performance situations it makes more sense if a tuning change affect only 
those notes which occur subsequent to the change, and not affect sounding notes. But there are also 
situations in which tuning changes should take place instantaneously, as specified in the standard, and 
should affect sounding notes without disrupting their continuity. 
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If the instrument responds well in the latter situation, some work-around is possible for the former. The 
reverse is not true. Therefore the standard requires that tuning changes immediately affect sounding 
notes. Manufacturers might, however, consider implementing a switchable “instantaneous/next-note-on” 
option within an instrument. 


Single Note Retuning is intended for performance. Because of there are two primary concerns: 1) the 
RAM required for temporary copies of tuning tables; and 2) the computational load of smoothly updating 
the pitch of affected active notes. It is clear that in order to recognize the Single Note Retune message, a 
copy of the current Tuning Program needs to be kept in RAM. In a multi-timbral environment there is 
potentially a copy for each virtual instrument. A high-end instrument could afford the upwards of 8K of 
RAM needed for per-virtual-instrument copies. More modest instruments may choose to only implement 
one alterable RAM table and either make it available only to the basic channel virtual instrument or 
require that all instruments share the same tuning. Provided that it is explained in the user’s manual, 
any of these methods is acceptable. 


Additional information on alternate tunings: 
The Just Intonation Network 

MIDI Tuning Standards Committee 

535 Stevenson St. 

San Francisco, CA 94103 
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GENERAL MIDI SYSTEM MESSAGES 


There is a defined set of Universal Non-Real Time SysEx messages for General MIDI (sub-ID#1 = 09). 
The current messages (below) turn GM mode on/off on a sound module (should it have more than one 
mode of operation): 


Turn General MIDI System On: 





FO 7E <device ID> 09 O01 F7 








FO 7E Universal Non-Real Time SysEx header 
<device ID> ID of target device (suggest using 7F ‘All Call’) 
09 sub-ID#1 = General MIDI message 

01 sub-ID#2 = General MIDI On 

F7 EKOX 


Turn General MIDI System Off 


FO 7E <device ID> 09 02 F7 








FO 7E Universal Non-Real Time SysEx header 
<device ID> ID of target device (suggest using 7F ‘All Call’) 
09 sub-ID#1 = General MIDI message 

02 sub-I[D#2 = General MIDI Off 

F7 EOX 


2 System Exclusive Messages 


MTC FULL MESSAGE, USER BITS, REAL TIME CUEING 


While MTC Quarter Frame messages (System Common) handle the basic running work of the system, 
they are not suitable for use when equipment needs to be fast-forwarded or rewound, located or cued to a 
specific time, as sending them continuously at accelerated speeds would unnecessarily clog up or outrun 
the MIDI data lines. For these cases, MTC Full Messages are used, which encode the complete time into 
a single message. After sending a Full Message, the time code generator can pause for any mechanical 
devices to shuttle (or "autolocate") to that point, and then resume running by sending quarter frame 
messages. 


Universal System Exclusive Real Time sub-ID#1 (01) is used for the MTC Full Message, and for defining 
MTC User Bits. Real Time sub-ID#1 (05) is used for MIDI Cueing. 


See the separate MTC Detailed Specification for complete details. 


MIDI SHOW CONTROL 


The purpose of MIDI Show Control is to allow MIDI systems to communicate with and to control 
dedicated intelligent control equipment in theatrical, live performance, multi-media, audio-visual and 
similar environments. Applications may range from a simple interface through which a single lighting 
controller can be instructed to GO, STOP or RESUME, to complex communications with large, timed 
and synchronized systems utilizing many controllers of all types of performance technology. 


MIDI Show Control uses a single Universal System Exclusive Real Time sub-ID#1 (02) for all Show 
commands (transmissions from Controller to Controlled Device). 


See the separate MSC Detailed Specification for complete details. 
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NOTATION INFORMATION 


Universal System Exclusive Real Time subID#1 (03) is used for communicating musical structure 
information in real time. 


The messages include Bar Marker, Time Signature (Delayed), and Time Signature (Immediate). 


BAR MARKER 


The Bar Marker message specifies that the next MIDI clock received is the first clock of a measure, and 
thus a new bar. 


The message format is as follows: 


FO 7F <device ID> 03 01 aa aa F7 





FO 7F Universal Real Time SysEx Header 
<device ID> ID of target device (default = 7F [all]) 
03 sub ID#1 = Notation Information 
01 sub ID#2 = Bar Number Message 
aa aa bar number; Isb first 
[00 40] not running 
[01 40] - [00 00] count-in 
[01 00] - [7E 3F] bar number in song 
[7F 3F] running; bar number unknown 


F7 EOX 


The numbering system uses the largest possible negative number as the “not running” flag; count-in 
bars are negative numbers until they reach zero, which is the last bar of count-in (systems that have 
only 1 bar of count-in don’t have to deal with negative numbers — just count from “zero” on up); bar 
numbers then increment through positive numbers, with the highest positive number reserved as 
“running, but I don’t know the bar number” (or the bar number has exceeded 8K). 


If MIDI clocks (F8s) are also being sent, this bar number takes effect at the next received F8. If MTC but 
no MIDI clocks are being sent, this bar number takes effect at the next received F1 xx. It may be 
displayed as soon as received (in the event that it was sent while a drum machine or sequencer is 
paused, but has located to a new section of the song). 


Please note that this message is intended for information and high-level synchronization as opposed to 
low-level synchronization, and should not be taken as a substitute for other MIDI timing messages. 


The Bar Marker message is critical for other Notation messages (such as Time Signature) which have 
the option of taking effect immediately or on the next received Bar Marker message. In the later case, 
extra information can be sent at any time during the previous bar without taking effect. This will 
minimize clogging by allowing enough room between the last F8/F1 xx of a bar and the first F8/F1 xx of 
the next. With the Bar Marker being sent every bar, a receiver does not have to keep track of MIDI 
clocks to know exactly where it is. 


Therefore, it is strongly suggested that the Bar Number be sent immediately after the last F8 or F1 xx 


message of the previous bar, to prevent possible clogging, jitter, and/or message transposition (MIDI 
mergers may also want to be sensitive to this message to prevent it getting delayed past a following F8). 


TIME SIGNATURE 
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The Signature Messages are used to communicate a new time signature to a receiving device. There are 
two forms, Immediate and Delayed. The Immediate form (sub id #2 = 02H [bit 6 = reset]) takes effect 
upon receipt (or on the next received MIDI clock if synchronized via MIDI sync). The Delayed form (sub- 
ID#2 = 42H [bit 6 = set]) takes effect upon the receipt of the next Bar Marker message. However, it may 
be displayed immediately. 


Time Signature (Immediate): 


FO 7F <device id> 03 02 In nn dd bb cc bb [nn dd...] F7 

FO 7F Universal Real Time SysEx header 

<device id> ID of target device (default = 7F [all]) 

03 sub-ID#1 = Notation Information 

02 sub-I[D#2 = Time Signature - Immediate 

ln number of data bytes to follow 

nn number of beats (numerator) of time signature 

dd beat value (denominator) of time signature (negative power of 2) 

cc number of MIDI clocks in a metronome click 

bb number of notated 32nd notes in a MIDI quarter note 

[nn dd...] additional pairs of time signatures to define a compound time 
signature within the same bar. 

F7 EOX 


Time Signature (Delayed): 


FO 7F <device id> 03 42 In nn dd bb cc bb [nn dd...] F7 


FO 7F Universal Real Time SysEx header 

<device id> ID of target device (default = 7F [all]) 

03 sub-ID#1 = Notation Information 

42 sub-I[D#2 = Time Signature - Delayed 

ln number of data bytes to follow 

nn number of beats (numerator) of time signature 

dd beat value (denominator) of time signature 
(negative power of 2) 

cc number of MIDI clocks in a metronome click 

bb number of notated 32nd notes in a MIDI quarter note 

[nn dd...] additional pairs of time signatures to define a 
compound time signature within the same bar. 

F7 EOX 


The additional data in [nn dd...] must always be in pairs. If there are not additional time signatures 
specified, In (the length of the data) = 4. It is incremented by multiples of 2 for every extra time 
signature pair that exists within the bar. 


The data format here duplicates that of the Standard MIDI File Time Signature Meta Event (FF 58), 
with extra bytes for compound time signatures. The bytes for the compound time signatures were added 
at the end so that the current Meta Event could be extended to match the format of this message, while 
keeping the leading bytes of the event the same. 
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The burden is placed on the transmitter to indicate ahead of time what the time signature will be in the 
next bar. It is not the responsibility of the receiver to count clocks and decode it. It is intended that 
interpretation of the Notation family of messages be made as simple as possible for the receiver so that 
devices with displays (which may not be following MIDI clocks) could easily pass useful information to 
the user. 
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DEVICE CONTROL 


MASTER VOLUME AND MASTER BALANCE 


These messages are intended to produce the same effect as volume and balance controls on a stereo 
amplifier. They are intended mainly for General MIDI instruments (so that one Master Volume control 
can simultaneously fade out all the layers in a sound module, for example), although there may be wider 
applications. 


Because these messages are intended to address “devices” as opposed to MIDI “channels” they have been 
defined as Universal Real Time System Exclusive messages (sub-ID#1 = 04). The corresponding 
“channel” messages are the controllers Channel Volume (formerly Main Volume) (CC number 07) and 
Balance (CC number 08). 


Master Volume: 


FO 7F <device id> 04 01 vv vv F7 


FO 7F <device id> Universal Real Time SysEx header 


04 sub-ID#1 = Device Control 
01 sub-ID#2 = Master Volume 
vv vv Volume (Isb first); 00 00 = volume off 
F7 EOX 
Master Balance: 


FO 7F <device id> 04 02 bb bb F7 


FO 7F <device id> Universal Real Time SysEx header 


04 sub-ID#1 = Device Control 

02 sub-ID#2 = Master Balance 

bb bb Balance (sb first); 00 00 = hard left; 
7F 7F = hard right 

F7 EOX 


In order to properly respond to these messages and their channel-aimed counterparts, a device must 
internally track three volume and two balance scalars as follows: 


1. Received on its own ID (which matches its knob on the front panel; if no knob or if knob is not 
scanned then power up default is set at full volume) 


2. Received on the ‘All Call’ or ‘broadcast’ ID (7F) 
3. Channel messages. 
This way, each virtual/channel-based instrument can be individually mixed, then a device could be 


individually scaled, and then all devices could be brought down together without forgetting their 
individual levels. 
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MIDI MACHINE CONTROL 


MIDI Machine Control is a general purpose protocol which initially allows MIDI systems to 
communicate with and to control some of the more traditional audio recording and production systems. 
Applications may range from a simple interface through which a single tape recorder can be instructed 
to PLAY, STOP, FAST FORWARD or REWIND, to complex communications with large, time code based 
and synchronized systems of audio and video recorders, digital recording systems and sequencers. 


MIDI Machine Control uses two Universal Real Time System Exclusive messages (sub-ID#1's), one for 
Commands (transmissions from Controller to Controlled Device), and one for Responses (transmissions 


from Controlled Device to Controller). (sub-ID#1 = 06, 07) 


See the separate MMC Detailed Specification for complete details. 
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ADDITIONAL EXPLANATIONS AND APPLICATION 
NOTES 


RUNNING STATUS 


Running status is a convenient short cut in transmission of data which saves time and makes it easier to 
minimize delays of transmitted MIDI data from the actual performance. With Running Status, after the 
first message, additional messages of the same type (i.e. Note On messages on the same MIDI channel) 
are sent without repeating the status byte for every message. Receivers must understand that if a data 
byte is received as the first byte of a message, the most recent, or "running" status is assumed. 


For example, a note is normally played by transmitting a Note On Status Byte (90H) followed by the key 
number value (0kkkkkkk) and the velocity value bytes (Ovvvvvvv). With Running Status, all additional 
notes on the same MIDI channel can be played by simply transmitting the key number and velocity 
bytes. As long as all following data consists of Note Ons on the same MIDI channel the Note On status 
byte need not be sent again. 


Running Status is most useful for Note On and continuous controller messages. As notes can be turned 
off by sending a Note On with a velocity value of 0, long strings of note messages can be sent without 
sending a Status byte for each message. If the Note Off (8nH) message is used to turn notes off, a status 
byte must be sent. 


The following is an example of Running Status. On the top is a complete data stream with one Status 
Byte for each pair of Data Bytes. Below that is a compressed data stream with only one Status Byte: 


With 

Status 190H | |3CH | |27H | 

With 

Running 90H | [ 3CH] [27H | 

Status C Note On E Note On G Note On 
(Vel. = 39) (Vel. = 48) (Vel. = 37) 


oi ene [80H |[8CH ][40H | [90H ][3EH |[29H | 
With 


Bunning 90H ] I90H_] [3CH_] [27H ] [3CH ][00H_] [3EH ][29H_] 
C Note On C Note Off D Note On 
(Vel. = 39) (Vel. = 0) (Vel. = 41) 






While the above examples pertain to Note On messages, Running Status may also be used for all Mode 
and Control Change messages. Running Status can drastically reduce the amount of data sent by 
Continuous Controllers. 


In some cases, the receiver must keep the status byte of the mode messages in a Running Status buffer 
even though the mode message is designated for a channel other than the receiver's basic channel. For 
example, if an Omni Off mode message is sent followed by Running Status Control Change messages, 
the Control Change messages can be properly recognized even though the Omni Off message may have 
been ignored. 
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Running Status Buffer and RespBeseiver to Different Messages 
(Basic Channel = 3, Mode: Omni On) 


Message: Message: 
Omni Off on CH 1 (ignore) Controller 1 in CH 1 


value 37H (recogniz 
pole Valio 


Running Status 
Buffer 


The receiver should always hold the last status byte in a Running Status buffer in case the transmitter 
is utilizing Running Status to reduce the number of bytes sent. This also means the receiver has to 
determine how many data bytes (one or two) are associated with each message. It is recommended that 
the Running Status buffer be set up as follows: 


Buffer is cleared at power up. 

Buffer stores the status when a channel message is received. 

Buffer is cleared when a System Exclusive or Common status message is received. 
Nothing is done to the buffer during reception of real time messages. 

The data bytes are ignored when the value of the status buffer is 0 (zero). 


i OO ars 


There are currently two undefined System Common status bytes (F4H and F5H). Should one of these 
undefined messages be received, it should be ignored and the running status buffer should be cleared. 
There are currently two undefined Real Time status bytes (F9H, FDH). Since these may convey only 
timing information, they should always be ignored, and the running status buffer should remain 
unaffected. 


If Running Status is being used and a receiver is connected to a transmitter after the transmitter has 
powered on it will not play until the next Status byte is transmitted. For this reason it is reeommended 
that the status be refreshed every few seconds. 

To Summarize: 

A transmitter may or may not be programmed to take advantage of Running Status. Using Running 
Status, notes may be turned off by sending a Note On message with zero velocity . It is the responsibility 


of the receiver to always recognize both normal and running status modes. 


A receiver should take into consideration that a transmitter can send messages in either Running Status 
or normal modes. The following flowchart shows an example of an interrupt-driven routine: 
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Read Serial Input 


Bit 7 = 1 


Is ita 
Real-Time 
Message? 
No 
Store in 
Running Status 
Buffer 
Clear Third 
Byte Flag 


No Is this a 
Tune Request? 
Yes = F6H 


Yes 
fo) 


(do not Store it in FIHO 
increment 
pointer here) increnient 
Pointer + 1 
° 
° 


Buffer = F3 
ear Running or F1H 
Status Buffe 
Store Status 
into FIFO 


Store Data Byte 
into FIFO 
Increment 
Pointer + 2 


° 
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Less than EQ 


Buffer Less 
than FOH 
Buffer 
Greater 
than FOH 
: ’ 
Clear Running 
Status Buffe 


Ignore Status 


Bit 7 =0 
Third Byte Flag = 1 
Flag = 0 
Running Status 
Buffer = 0 
Ignore 
Buffer Data Byte 
Clear Third 
Byte Flag 
Store Third 
Byte into FIF 


Greater 


Less 
than 0 fhan 
COH 









Increment 
Pointer + 3 










Buffer = F2 






H Clear Running 
Status Buffe 


Set Third 
Byte Flag 


Store Status 
into FIFO 
Store Data Byte 
into FIFO 


(do not 
increment 


Buffer >= FOH 


pointer here 


—S 


° ° 
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ASSIGNMENT OF NOTE ON/OFF COMMANDS 


If an instrument receives two or more Note On messages with the same key number and MIDI channel, 
it must make a determination of how to handle the additional Note Ons. It is up to the receiver as to 
whether the same voice or another voice will be sounded, or if the messages will be ignored. The 
transmitter, however, must send a corresponding Note Off message for every Note On sent. If the 
transmitter were to send only one Note Off message, and if the receiver in fact assigned the two Note 
On messages to different voices, then one note would linger. Since there is no harm or negative side 
effect in sending redundant Note Off messages this is the recommended practice. 


VOICE ASSIGNMENT IN POLY MODE 


In Poly mode there are no particular rules which define how to assign voices when more than one Note 
On message is received and recognized. If more Note On messages are transmitted than the receiver is 
capable of playing, the receiver is free to use any method of dealing with this "overflow" situation (such 
as first vs. last note priority). The priority of voice assignments may follow the order in which Note On 
messages are received, the receiver's own keyboard control logic, or some other scheme. 


When a transmitter sends Note On and Off information to a receiving keyboard which is also being 
played, it is important for the receiver to distinguish the source of Note On/Off information. For example, 
a Note Off received from MIDI should not turn off a note that is being played on the receiver's own 
keyboard. Conversely, releasing a key on the receiver's own keyboard should not turn off a note being 
received from MIDI. 


"ALL NOTES OFF" FUNCTION WHEN SWITCHING MODES 


When a receiver is switching between Omni On/Off and Poly or Mono modes, all notes should be turned 
off . This is to avoid any unexpected behavior when the instrument's mode is switched. Caution should 
be taken to turn off only those note events received from MIDI and not those played on the receiver's 
keyboard. 


MIDI MERGING AND ALL NOTES OFF 


A sequencer replays previously recorded messages and merges them with any messages received at its 
MIDI In. A MIDI merging device combines two incoming data streams in real time. In either case the 
result is that a single MIDI data stream is communicating information produced by more than one 
transmitter. If an All Notes Off messages is passed through either a sequencer or merging device, then 
all connected devices will shut off their notes, though the All Notes Off may have only been intended for 
the notes turned on by one specific instrument. When an All Notes Off is received by a sequencer it 
should check to make sure that it does not conflict with any notes currently being played. Similarly, if an 
All Notes Off message is contained in the recorded sequence, it should not be sent if Note On data for 
that channel is being received. A MIDI merging device should feature the ability to selectively filter All 
Notes Off messages to avoid this problem. 


Mode messages with a second byte greater than 124 should be treated in the same way as the All Notes 
Off message since they also perform an All Notes Off function. 
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THE RELATIONSHIP BETWEEN THE HOLD PEDAL AND "ALL 
NOTES OFF" 


If Note Off messages are received while the hold pedal (controller 64 (40H)) is 'on' they must be 
recognized but not acted upon until the release of the hold pedal. The same is true for the All Notes Off 
message. A Hold or Sustain pedal 'On' message takes priority over Note Off and All Notes Off until it is 
released. 


All Notes Off should force voices to go to the release stage of the envelope, and not terminate the sound 
of the notes abruptly. 


MIDI Messages Transmitted: 


90 43 40 BO 40 7F 90 43 00 BO 7B 00 40 00 
(G On) (HOLD On) (G Off) (All Notes Off) (HOLD Off) 


re reese "All Notes Off", even though Note Off 


orcaled Dy Ane level ng neuumel has been received, since hold is still on. 


FURTHER DESCRIPTION OF HOLD PEDAL 


Hold and Second Release switches use controller number 64 (40H). Proper implementation of the hold 
pedal will maintain the envelope's sustain level. A"Hold 2" switch has been defined as controller 
number 69 (45H) as a means of implementing all other hold functions (e.g. "freeze" where envelopes etc. 
are frozen in their current state) and/or for implementing two different hold functions simultaneously. 
"Chord Hold" which holds only the notes held when the foot pedal is switched on, is equivalent to the 
Sostenuto controller 66. All notes played after the foot pedal is switched on are performed normally. 


PRIORITY OF MIDI RECEIVING 


An instrument capable of receiving and processing incoming MIDI data must give priority to its MIDI In 
port over its local functions such as the front panel or keyboard. It is critical that incoming data never be 
ignored or mishandled due to the processor's attention being elsewhere. 


At 31.25 Kbaud, one byte is sent every 320 microseconds, which means that proper handling of the 
received data during any long-term or ongoing MIDI communication will require a high speed 
microprocessor. For this reason, interrupts and FIFO (first in/first out) buffers are commonly used. As 
soon as possible after an interrupt is generated, received data can be stored in a FIFO buffer for 
processing later on. This data handling can take much less than 320 uS, allowing time for the 
microprocessor to handle other aspects of the instrument's operation. 


RELEASE OF OMNI 


As a transmitter has no way of knowing what channel a receiver is on it is best to always be able to turn 
Omni off by means of front panel controls on an instrument. 
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BASIC CHANNEL OF A SEQUENCER 


To a receiver, the output of a MIDI sequencer is identical to the output of any MIDI transmitter with 
the possible exception of added Real Time bytes. A transmitting instrument sends on a particular 
channel which a sequencer then records and re-transmits. Thus, a sequencer does not need a Basic 
Channel as do other instruments. However, this does not prevent a sequencer from having a Basic 
Channel for recognizing mode messages or changing channels. 


TRANSPOSING 


If key transpose is implemented on a keyboard instrument, the MIDI key number 60 can be assigned to 
a physical key other than middle C. Transposition is allowed on both transmitters and receivers. The 
transposing system in a device should separately affect the keyboard data and incoming MIDI data 
going to the voice module. To avoid confusion it is a good idea to use an indicator to show when key 
transpose is active. 
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MIDI IMPLEMENTATION CHART INSTRUCTIONS 


The standard MIDI Implementation Chart is used as a quick reference of transmitter and receiver 
functions so that users can easily recognize what messages and functions are implemented in the 
instrument. This chart should be included in the users manual of all MIDI products. For example, if a 
user intends to connect two MIDI instruments, they might compare the "Transmitted" part of one 
instrument's chart, with the "Recognized" part of the other instrument's chart by overlapping them. For 
this reason each chart should be the same size and have the same number of lines. 


GENERAL 


1. 


The "| ]" brackets at the top of the chart is used for the instrument's name such as, [LINEAR 
WAVETABLE SYNTHESIZER]. 


2. The item "MODEL" should be used for the model number, such as "LW-1". 

3. The body of the implementation chart is divided into four columns. The first column is the 
specific function or item, the next two columns give information on whether the specified 
function is transmitted and/or received, and the fourth column is used for remarks. This last 
column is useful to explain anything unique to this implementation. 

FUNCTION DESCRIPTION 

1. BASIC CHANNEL: 

Default: | Channel which is assigned when power is first applied to unit. 
Changed: The channels which can be assigned from the instrument's front panel. 
2. MODE: 
Default: This is the channel mode used by a Transmitter and Receiver when power is 
first applied. This should be written as Mode x (where x is 1 through 4), as shown on 
the bottom of sheet. 
Messages: These are the mode messages which can be transmitted or received, such as 
OMNI ON/OFF, MONO ON, and POLY ON. MONO ON and POLY ON may be 
written in the short form "MONO", "POLY". 
Altered: This shows the channel modes which are not implemented by a receiver and 
the modes which are substituted. For example, if the receiver cannot accept "MONO 
ON" mode, but will switch to "OMNI ON" mode in order to receive the MIDI data, the 
following expression should be used: "MONO ON > OMNI ON" or "MONO > OMNI". 
3. NOTE NUMBER: 


Note Number: The total range of transmitted or recognized notes. 
True Voice: Range of received note numbers falling within the range of true notes 
produced by the instrument. 
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10. 


11. 


12. 


13. 
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VELOCITY: 


NOTE ON/NOTE OFF Velocity is assigned either an "o" for implemented or an "x" for not 


implemented. In the space following the "o" or "x" it may be mentioned how the 
Note On or Off data is being transmitted. 


AFTERTOUCH: 

"o" for implemented or an "x" for not implemented 

PITCH BEND: 

"o" for implemented or an "x" for not implemented 

CONTROL CHANGE: 

Space is given in this area for listing of any implemented control numbers. An "o" or "x" should be 

placed in the appropriate Transmitted or Recognized column and the function of the specified 

control number should be listed in the remarks column. 

PROGRAM CHANGE: 

"o" for implemented or an "x" for not implemented. If implemented, the range of numbers should 

be included. 

True # (Number): The range of the program change numbers which correspond to the 
actual number of patches selected. 


SYSTEM EXCLUSIVE: 


"o" for implemented or an "x" for not implemented. A full description of the instrument's System 
Exclusive implementation should be included on separate pages. 


SYSTEM COMMON: 


"o" for implemented or an "x" for not implemented. The following abbreviations are used: 


Song Pos = Song Position 

Song Sel = Song Select 

Tune = Tune Request 
SYSTEM REAL TIME: 


"o" for implemented or an "x" for not implemented. The following abbreviations are used: 
Clock = Timing Clock 
Commands = Start, Continue and Stop 

AUX. MESSAGES: 


"o" for implemented or an "x" for not implemented. The following abbreviations are used: 


Aux = Auxiliary 
Active Sense = Active Sensing 
NOTES: 


The "Notes" column can be any comments such as: 
Power Up messages transmitted, implementation of program changes to additional 
memory banks, etc. 
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Date: 
Model MIDI Implementation Chart Version: 






Default 
Mode Messages 
Altered 








Note On 
Velocity Note Off 






After Key's 
Touch Channel 












Control 
Change 








System Song Position 


Program 

Change True Number 
Song Select 

Common Tune Request 

System Clock 

Real Time Commands 


se ae 











Aux All Notes Off 
Messages _ Active Sensing 
System Reset 






Mode 1: Omni On, Poly Mode 2: Omni On, Mono O: Yes 
Mode 3: Omni Off, Poly Mode 4: Omni Off, Mono X: No 


STATUS 
Binary 
D7--D0O 


TABLE I 


SUMMARY OF STATUS BYTES 


NUMBER DESCRIPTION 
OF DATA 
BYTES 


Channel Voice Messages 


8nH 


9nH 


AnH 


BnH 


CnH 


DnH 


EnH 


Channel Mode 


BnH 


1000nnnn 


1001innnn 


1010nnnn 


1011nnnn 
1100nnnn 


1101nnnn 


1110nnnn 


Messages 





1011nnnn 


System Messages 


FOH 


NOTES: 


Tables 


11110000 


11110sss 


PETITE 


nnnn: 


11iiliiii: 


SSS: 
Ctts 
XXX? 


2 Note Off 
2 Note On (a velocity of 0 = Note Off) 
2 Polyphonic key pressure/Aftertouch 
2 Control change 
1 Program change 
1 Channel pressure/After touch 
2 Pitch bend change 
(01111xxx) 2 Selects Channel Mode 

RRRKK System Exclusive 
0 to2 System Common 
0 System Real Time 


N-1, where N = Channel #, 
i.e. 0000 is Channel 1, 0001 is Channel 2, 
and 1111 is Channel 16. 


Identification 

1to7 

0 to7 

Channel Mode messages are sent under the same Status Byte as the 
Control Change messages (BnH). They are differentiated by the first data 
byte which will have a value from 121 to 127 for Channel Mode 
messages. 
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TABLE II 


CHANNEL VOICE MESSAGES 
STATUS DATA BYTES DESCRIPTION 

Hex Binary 
8nH 1000nnnn Okkkkkkk Note Off 

Ovvvvvvv vvvvvvv: note off velocity 
9nH 1001nnnn Okkkkkkk Note On 

OVVVVVVV vvvvvvv # 0: velocity 

vvvvvvv = 0: note off 

AnH 1010nnnn Okkkkkkk Polyphonic Key Pressure (Aftertouch) 

Ovvvvvvv VVVVVVV: pressure value 
BnH 1011nnnn Oceccecce Control Change (See Table HI) 

OVVVVVVV ccccccc: control # (0-119) 


vvvvvvv: control value 
ececcce = 120 thru 127: Reserved. (See Table IV) 


CnH 1100nnnn Oppppppp Program Change 
Ppppppp: program number (0-127) 


DnH 1101nnnn OvvVvVVVV Channel Pressure (Aftertouch) 
VVVVVVV: pressure value 


EnH 1110nnnn OVVVVVVV Pitch Bend Change LSB 
OVVVVVVV Pitch Bend Change MSB 
NOTES: 
1.nnnn: Voice Channel number (1-16, coded as defined in Table I notes) 
2. kkkkkkk: note number (0 - 127) 


3. vvvvvvv: key velocity 
A logarithmic scale is recommended. 


4. Continuous controllers are divided into Most Significant and Least Significant Bytes. If only seven bits of resolution 
are needed for any particular controllers, only the MSB is sent. It is not necessary to send the LSB. If more resolution is 
needed, then both are sent, first the MSB, then the LSB. If only the LSB has changed in value, the LSB may be sent 
without re-sending the MSB. 
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TABLE I 


CONTROLLER NUMBERS 
CONTROL NUMBER CONTROL FUNCTION 
(2nd Byte value) 
Decimal Hex 
0 00H Bank Select 
1 01H Modulation wheel or lever 
2 02H Breath Controller 
3 03H Undefined 
4 04H Foot controller 
5 05H Portamento time 
6 06H Data entry MSB 
7 07H Channel Volume (formerly Main Volume) 
8 08H Balance 
9 09H Undefined 
10 OAH Pan 
11 OBH Expression Controller 
12 OCH Effect Control 1 
13 ODH Effect Control 2 
14-15 OE-OFH Undefined 
16-19 10-13H General Purpose Controllers (#'s 1-4) 
20-31 14-1FH Undefined 
32-63 20-3FH LSB for values 0-31 
64 40H Damper pedal (sustain) 
65 41H Portamento On/Off 
66 42H Sostenuto 
67 43H Soft pedal 
68 44H Legato Footswitch (vv = 00-3F:Normal, 40-7F=Legatto) 
69 45H Hold 2 
70 46H Sound Controller 1 (default: Sound Variation) 
71 47H Sound Controller 2 (default: Timbre/Harmonic Intensity) 
F2 48H Sound Controller 3 (default: Release Time) 
73 49H Sound Controller 4 (default: Attack Time) 
74 4AH Sound Controller 5 (default: Brightness) 
75-719 4BH-4FH Sound Controllers 6-10 (no defaults) 
80-83 50-53H General Purpose Controllers (#'s 5-8) 
84 54H Portamento Control 
85-90 55-5AH Undefined 
91 5BH Effects 1 Depth (formerly External Effects Depth) 
92 5CH Effects 2 Depth (formerly Tremolo Depth) 
93 5DH Effects 3 Depth (formerly Chorus Depth) 
94 5EH Effects 4 Depth (formerly Celeste (Detune) Depth) 
95 5FH Effects 5 Depth (formerly Phaser Depth) 
96 60H Data increment 
97 61H Data decrement 
98 62H Non-Registered Parameter Number LSB 
99 63H Non-Registered Parameter Number MSB 
100 64H Registered Parameter Number LSB 
101 65H Registered Parameter Number MSB 
102-119 66-77H Undefined 
120-127 78-7FH Reserved for Channel Mode Messages 


Tables T-3 
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TABLE IIIa 


REGISTERED PARAMETER NUMBERS 


Parameter Number Function 

LSB MSB 
00H 00H Pitch Bend Sensitivity 
01H 00H Fine Tuning 
02H 00H Coarse Tuning 
03H OOH Tuning Program Select 
04H OOH Tuning Bank Select 
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TABLE IV 


CHANNEL MODE MESSAGES 
STATUS DATA BYTES DESCRIPTION 
Hex Binary 
Bn 1011nnnn Occccccc Mode Messages 
OVVVVVVV 

cccccce 120: All Sound Off 

VVVVVVV 0 

ccccccce = 121: Reset All Controllers 

VVVVVVV 0 

eccccce = 122:Local Control 

VVVVVVV 0, Local Control Off 

vvvvvvv = 127, Local Control On 

ececece = 123: All Notes Off 

vvvvvvv = 0 

eccceccece = 124: Omni Mode Off (All Notes Off) 

vvvvvvv = 0O 

ececccece = 125:Omni Mode On (AI Notes Off) 

vvvvvvv = 0 

cccccce 126: Mono Mode On (Poly Mode Off) 
(All Notes Off) 

VVVVVVV M, where M is the number of 
channels. 

VVVVVVV 0, the number of channels equals the 
number of voices in the receiver. 

ccccccc 127: Poly Mode On (Mono Mode Off) 
(All Notes Off) 

VVVVVVV 0 


NOTES: 
1. nnnn: Basic Channel number (1-16) 
2. ccccccc: Controller number (121 - 127) 


3. vvvvvvv: Controller value 


Tables 
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STATUS 

Hex Binary 

F1H 11110001 
F2H 11110010 
F3H 11110011 
F4H 11110100 
F5H 11110101 
F6H 11110110 
F7H LILLOL 11, 
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TABLE V 


SYSTEM COMMON MESSAGES 


DATA BYTES 


Onnndddd 


01111111 
Ohhhhhhh 


Osssssss 


none 


none 


DESCRIPTION 


MIDI Time Code Quarter Frame 
nnn: Message Type 

dddd: Values 

Song Position Pointer 
1111111: (Least significant) 
hhhhhhh: (Most significant) 


Song Select 
sssssss: Song# 


Undefined 
Undefined 
Tune Request 


EOX: "End of System Exclusive" flag 
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STATUS 

Hex Binary 

F8H 11111000 
F9H 11111001 
FAH 11111010 
FBH 11111011 
FCH 11111100 
FDH 11111101 
FEH 11111110 
FFH 11111111 

Tables 


TABLE VI 


SYSTEM REAL TIME MESSAGES 


DATA BYTES DESCRIPTION 


Timing Clock 
Undefined 
Start 

Continue 

Stop 
Undefined 
Active Sensing 
System Reset 
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TABLE VII 


SYSTEM EXCLUSIVE MESSAGES 





STATUS DATA BYTES DESCRIPTION 
Hex Binary 
FOH 11110000 SOX: Start of System Exclusive Status Byte 
Oiiiiiii System Exclusive Sub-ID (see note 1) 
(00 — 7CH) Manufacturer Identification 
(7DH) Non Commercial System Exclusive ID 
(7EH) Non-Real Time System Exclusive 
(7FH) Real Time System Exclusive 
Oddddddd 


Any number of data bytes may be sent here, for any purpose, as 
long as they all have a zero in the most significant bit. (see note 2) 


Odddddaa 


F7H 11110111 EOX: End of System Exclusive 


A) Manufacturer identification (0-124). If the first byte of this ID is 0, the following two bytes are used as 
extensions to the Manufacturer ID. See Table VIIb for a listing of currently assigned Manufacturer ID numbers. 
A Manufacturers ID may be obtained from the MIDI Manufacturers Association. 

B) ID 7DH (125) is reserved for non-commercial use (e.g. schools, research, etc.) and is not to be used on any 
product released to the public. 

C) ID 7EH (126) and 7FH (127) are used for Universal System Exclusive extensions to the MIDI specification. 
See Table VIa for a listing of currently defined Non-Real Time and Real Time messages. 


2. Oddddddd: 


All bytes between the System Exclusive Status byte and EOX must have zeroes in the Most Significant Bit -- which 
therefore makes them Data Bytes -- with the exception of System Real Time Status Bytes (F 8H-FFH) (see Table 
VI). Any other Status Byte that appears between the SOX (F0H) and EOX (F7H) will be considered an EOX 
message, and terminate the System Exclusive message. 
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SUB-ID #1 


TABLE Vila 


CURRENTLY DEFINED UNIVERSAL SYSTEM EXCLUSIVE MESSAGES 


Non-Real Time (7EH) 


00 
Ol 
02 
03 
04 


05 


06 


07 


08 


09 


7B 
AE 
7D 
7E 
TF 


Tables 


(not used) 
(not used) 
(not used) 
nn 
00 
01 
02 
03 
04 
05 
06 
07 
08 
09 
OA 
OB 
Oc 
OD 
OE 
nn 
01 
02 
nn 
01 
02 
nn 
01 
02 
03 
nn 
00 
01 
nn 
01 
02 
(not used) 
(not used) 
(not used) 
(not used) 
(not used) 


SUB-ID #2 


DESCRIPTION 


Unused 
Sample Dump Header 
Sample Data Packet 
Sample Dump Request 
MIDI Time Code 
Special 
Punch In Points 
Punch Out Points 
Delete Punch In Point 
Delete Punch Out Point 
Event Start Point 
Event Stop Point 
Event Start Points with additional info. 
Event Stop Points with additional info. 
Delete Event Start Point 
Delete Event Stop Point 
Cue Points 
Cue Points with additional info. 
Delete Cue Point 
Event Name in additional info. 
Sample Dump Extensions 
Multiple Loop Points 
Loop Points Request 
General Information 
Identity Request 
Identity Reply 
File Dump 
Header 
Data Packet 
Request 
MIDI Tuning Standard 
Bulk Dump Request 
Bulk Dump Reply 
General MIDI 
General MIDI System On 
General MIDI System Off 
End Of File 
Wait 
Cancel 
NAK 
ACK 
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CURRENTLY DEFINED UNIVERSAL SYSTEM EXCLUSIVE MESSAGES - continued 


Real Time (7FH) 


00 
Ol 


02 


03 


04 


05 


06 


07 


08 


NOTES: 





Unused 
MIDI Time Code 
Full Message 
User Bits 
MIDI Show Control 
MSC Extensions 
TE MSC Commands 
(Detailed in MSC documentation) 
Notation Information 
Bar Number 
Time Signature (Immediate) 
Time Signature (Delayed) 
Device Control 
Master Volume 
Master Balance 
Real Time MTC Cueing 
Special 
Punch In Points 
Punch Out Points 
(Reserved) 
(Reserved) 
Event Start points 
Event Stop points 
Event Start points with additional info. 
Event Stop points with additional info. 
(Reserved) 
(Reserved) 
Cue points 
Cue points with additional info. 
(Reserved) 
Event Name in additional into. 
MIDI Machine Control Commands 
TE MMC Commands 
(Detailed in MMC documentation) 
MIDI Machine Control Responses 
TE MMC Commands 
(Detailed in MMC documentation) 
MIDI Tuning Standard 
Note Change 


1. The standardized format for both Real Time and Non-Real Time messages is as follows: 
FOH <ID number> <device ID> <sub-ID#1> <sub-ID#2>...... F7H 


2. Additional details and descriptions of MTC MSC and MMC are available as separate documents. 
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NUMBER 


American Group 


00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 


00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 


Tables 


01H 
02H 
03H 
04H 
05H 
06H 
07H 
08H 
09H 
OAH 
OBH 
OCH 
ODH 
OEH 
OFH 
10H 
11H 
12H 
13H 
14H 
15H 
16H 
17H 
18H 
19H 
1AH 
1BH 
1CH 
1DH 
1FH 
01H 
07H 
08H 
09H 
OAH 
OBH 
OCH 
ODH 
OEH 
10H 
11H 
14H 
15H 
16H 
17H 
18H 
19H 
1AH 
1BH 
1CH 
1DH 
1EH 


TABLE VIIb 


SYSTEM EXCLUSIVE MANUFACTURER'S ID NUMBERS 


MANUFACTURER 


Sequential 

IDP 
Voyetra/Octave-Plateau 
Moog 

Passport Designs 
Lexicon 

Kurzweil 

Fender 

Gulbransen 

AKG Acoustics 

Voyce Music 
Waveframe Corp 

ADA Signal Processors 
Garfield Electronics 
Ensoniq 

Oberheim 

Apple Computer 

Grey Matter Response 
Digidesign 

Palm Tree Instruments 
JLCooper Electronics 
Lowrey 

Adams-Smith 

Emu Systems 
Harmony Systems 
ART 

Baldwin 

Eventide 

Inventronics 

Clarity 

Time Warner Interactive 
Digital Music Corp. 
IOTA Systems 

New England Digital 
Artisyn 

IVL Technologies 
Southern Music Systems 
Lake Butler Sound Company 
Alesis 

DOD Electronics 
Studer-Editech 

Perfect Fretworks 

KAT 

Opcode 

Rane Corp. 

Anadi Inc. 

KMX 

Allen & Heath Brenell 
Peavey Electronics 

360 Systems 

Spectrum Design and Development 
Marquis Music 


NUMBER 


00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
OOH 
OOH 
00H 
00H 
00H 
00H 
00H 
00H 
00H 


00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
OOH 
OOH 
00H 
00H 
00H 
00H 
00H 
00H 
00H 


1FH 
20H 
21H 
24H 
25H 
26H 
29H 
2AH 
2BH 
2DH 
2EH 
2FH 
30H 
31H 
32H 
33H 
34H 
35H 
37H 
38H 
39H 
3AH 
3CH 
3DH 
3EH 
3FH 


42H 


44H 


4CH 
4DH 
4EH 





50H 
51H 
52H 
53H 
54H 
55H 
56H 
57H 
58H 
59H 
5AH 
5BH 
5CH 


MANUFACTURER 


Zeta Systems 

Axxes 

Orban 

KTI 

Breakaway Technologies 
CAE 

Rocktron Corp. 
PianoDisc 

Cannon Research Group 
Rogers Instrument Corp. 
Blue Sky Logic 

Encore Electronics 
Uptown 

Voce 

CTI Audio, Inc. (Music. Intel Dev.) 
S&S Research 
Broderbund Software, Inc. 
Allen Organ Co. 

Music Quest 

APHEX 

Gallien Krueger 

IBM 

Hotz Instruments Technologies 
ETA Lighting 

NSI Corporation 

Ad Lib, Inc. 

Richmond Sound Design 
Microsoft 

The Software Toolworks 
Niche/RJMG 

Intone 

GT Electronics/Groove Tubes 
InterMIDI, Inc. 
Timeline Vista 

Mesa Boogie 

Sequoia Development 
Studio Electronics 
Euphonix 

InterMIDI 

MIDI Solutions 

3DO Company 
Lightwave Research 
Micro-W 

Spectral Synthesis 

Lone Wolf 

Studio Technologies 
Peterson EMP 

Atari 

Marion Systems 

Design Event 
Winjammer Software 
AT&T Bell Labs 






































NUMBER 
OOH OOH SEH 
OOH OOH 5SFH 
OOH OOH 60H 
OOH OOH 61H 
OOH OOH 62H 
OOH OOH 63H 
OOH OOH 64H 
OOH OOH 65H 
OOH OOH 66H 
OOH OOH 67H 
OOH OOH 68H 
OOH OOH 69H 
OOH OOH 6AH 
OOH OOH 6BH 
OOH OOH 6CH 
OOH OOH 6DH 
OOH OOH 6EH 
OOH OOH 6FH 
OOH OOH 70H 
OOH OOH 71H 
OOH OOH 72H 
OOH OOH 73H 
OOH OOH 74H 
OOH OOH 75H 
OOH OOH 76H 
OOH OOH 77H 
OOH OOH 78H 
OOH OOH 79H 
OOH OOH 7AH 
OOH OOH 7BH 
OOH OOH 7CH 
OOH OOH 7DH 
OOH OOH 7EH 
OOH OOH 7FH 
OOH OOH 80H 
OOH OOH 81H 
OOH OOH 82H 


European Group 
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20H 
21H 
22H 
24H 
25H 
26H 
27H 
28H 
29H 
2AH 
2BH 
2CH 
2FH 
30H 
31H 
33H 
34H 


SYSTEM EXCLUSIVE MANUFACTURER'S ID NUMBERS - continued 


MANUFACTURER 


Symetrix 

MIDI the World 
Desper Products 
Micros 'N MIDI 
Accordians Intl 
EuPhonics 

Musonix 

Turtle Beach Systems 
Mackie Designs 
Compuserve 

BES Technologies 
QRS Music Rolls 

PG Music 

Sierra Semiconductor 
EpiGraf Audio Visual 
Electronics Deiversified 
Tune 1000 

Advanced Micro Devices 
Mediamation 

Sabine Music 

Woog Labs 

Micropolis 

Ta Horng Musical Inst. 
eTek (formerly Forte) 
Electrovoice 

Midisoft 

Q-Sound Labs 
Westrex 

NVidia 

ESS Technology 
MediaTrix Peripherals 
Brooktree 

Otari 

Key Electronics 
Crystalake Multimedia 
Crystal Semiconductor 
Rockwell Semiconductor 


Passac 

SIEL 

Synthaxe 

Hohner 

Twister 

Solton 

Jellinghaus MS 
Southworth Music Systems 
PPG 

JEN 

SSL Limited 

Audio Veritrieb 

Elka 

Dynacord 

Viscount 

Clavia Digital Instruments 
Audio Architecture 


NUMBER 


00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
OOH 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 
00H 


20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 
20H 


35H 
39H 
3BH 
3CH 
3DH 
3EH 
3FH 
00H 
01H 
02H 
04H 
06H 
07H 
09H 
OAH 
OBH 
OCH 
ODH 
OEH 
OFH 
10H 
11H 
13H 
15H 
16H 
17H 
18H 
19H 
1AH 
1BH 
1CH 
1DH 
1EH 
1FH 
20H 
21H 
22H 
23H 
24H 
25H 
26H 
27H 
28H 
29H 
2AH 
2BH 
2CH 
2DH 
2EH 


MANUFACTURER 


GeneralMusic Corp. 
Soundcraft Electronics 
Wersi 

Avab Electronik Ab 
Digigram 

Waldorf Electronics 
Quasimidi 

Dream 

Strand Lighting 

Amek Systems 

Bohm Electronic 

Trident Audio 

Real World Studio 

Yes Technology 
Audiomatica 
Bontempi/Farfisa 

F.B.T. Elettronica 
MidiTemp 

LA Audio (Larking Audio) 
Zero 88 Lighting Limited 
Micon Audio Electronics GmbH 
Forefront Technology 
Kenton Electronics 

ADB 

Marshall Products 

DDA 

BSS 

MA Lighting Technology 
Fatar 

QSC Audio 

Artisan Classic Organ 
Orla Spa 

Pinnacle Audio 

TC Electonics 

Doepfer Musikelektronik 
Creative Technology Pte 
Minami/Seiyddo 
Goldstar 

Midisoft s.a.s di M. Cima 
Samick 

Penny and Giles 

Acorn Computer 

LSC Electronics 
Novation EMS 
Samkyung Mechatronics 
Medeli Electronics 
Charlie Lab 

Blue Chip Music Tech 
BEE OH Corp 
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NUMBER 


SYSTEM EXCLUSIVE MANUFACTURER'S ID NUMBERS - continued 


MANUFACTURER 


Japanese Group (as of 10/92) 


Tables 


40H 
41H 
42H 
43H 
44H 
46H 
47H 
48H 
49H 
4AH 
4BH 
4CH 
4DH 
4EH 
50H 
51H 
52H 
53H 
54H 
55H 


Kawai 

Roland 

Korg 

Yamaha 

Casio 

Kamiya Studio 

Akai 

Japan Victor 

Mesosha 

Hoshino Gakki 

Fujitsu Elect 

Sony 

Nisshin Onpa 

TEAC 

Matsushita Electric 
Fostex 

Zoom 

Midori Electronics 
Matsushita Communication Industrial 
Suzuki Musical Inst. Mfg. 


NUMBER 


MANUFACTURER 
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TABLE VIII 


ADDITIONAL OFFICIAL SPECIFICATION DOCUMENTS PUBLISHED BY 
THE MIDI MANUFACTURERS ASSCOCIATION 


DOCUMENT TITLE 


MIDI Time Code 

MIDI Show Control 1.1 
MIDI Machine Control 
Standard MIDI Files 

General MIDI System Level 1 


*New Version, February 1996 


DESCRIPTION 


Recommended Practice RP004/RP008 
Recommended Practice RP002 /RPO14* 
Recommended Practice RP013 
Recommended Practice RPOO1 
Recommended Practice RPOO3 
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